Mark Mielke wrote:
> Stefan Fuhrmann wrote:
>> On 04.01.2012 19:42, Julian Foad wrote:
>>> The extended author fields are delivered through revision
>>> properties [that] are readable but not writable by clients.
>>
>> Maybe, I missed something in your post but I want
>> to stress that is
On 01/08/2012 09:55 PM, Stefan Fuhrmann wrote:
On 04.01.2012 19:42, Julian Foad wrote:
The extended author fields are delivered through revision
properties. The values are UTF-8 text. These revision properties
are readable but not writable by clients.
Maybe, I missed something in your po
On 04.01.2012 19:42, Julian Foad wrote:
The extended author fields are delivered through revision properties. The
values are UTF-8 text. These revision properties are readable but not writable
by clients.
Maybe, I missed something in your post but I want
to stress that is very important
kmra...@rockwellcollins.com wrote on Thu, Jan 05, 2012 at 14:03:37 -0600:
> Mark Mielke wrote on 01/05/2012 12:36:10 PM:
> > On 01/05/2012 12:34 PM, Branko Čibej wrote:
> > > On 05.01.2012 18:25, Mark Mielke wrote:
> > >> On 01/05/2012 12:04 PM, Branko Čibej wrote:
> > >>> Ha, but svn:author curre
Mark Mielke wrote on 01/05/2012 12:36:10 PM:
> On 01/05/2012 12:34 PM, Branko Čibej wrote:
> > On 05.01.2012 18:25, Mark Mielke wrote:
> >> On 01/05/2012 12:04 PM, Branko Čibej wrote:
> >>> Ha, but svn:author currently fills that role. So why add another
> >>> property?
> >> If svn:author is defin
On 01/05/2012 12:34 PM, Branko Čibej wrote:
On 05.01.2012 18:25, Mark Mielke wrote:
On 01/05/2012 12:04 PM, Branko Čibej wrote:
Ha, but svn:author currently fills that role. So why add another
property?
If svn:author is defined as the primary key and also the
authentication key, it does seem s
On 05.01.2012 18:25, Mark Mielke wrote:
> On 01/05/2012 12:04 PM, Branko Čibej wrote:
>> On 05.01.2012 11:32, Julian Foad wrote:
>>> Branko wrote:
[...] you have to define which of the properties must have values
that are unique within the given repository; what is the primary key;
>>> O
On 01/05/2012 12:04 PM, Branko Čibej wrote:
On 05.01.2012 11:32, Julian Foad wrote:
Branko wrote:
[...] you have to define which of the properties must have values
that are unique within the given repository; what is the primary key;
OK, let's say:
The "svn:author:authn-id" value is the prim
On 01/05/2012 07:44 AM, Johan Corveleyn wrote:
On Wed, Jan 4, 2012 at 7:42 PM, Julian Foad wrote:
[ ... ]
SERVER DESIGN
Any time the server is about to send a set of revision properties to
the client, the server looks up the extended author fields and adds
corresponding properties to the s
On 05.01.2012 11:32, Julian Foad wrote:
> Branko wrote:
>> [...] you have to define which of the properties must have values
>> that are unique within the given repository; what is the primary key;
> OK, let's say:
>
> The "svn:author:authn-id" value is the primary key, and so is unique within a
On Wed, Jan 4, 2012 at 7:42 PM, Julian Foad wrote:
[ ... ]
> SERVER DESIGN
> Any time the server is about to send a set of revision properties to
> the client, the server looks up the extended author fields and adds
> corresponding properties to the set of revision properties that it
> reports
Branko wrote:
> [...] you have to define which of the properties must have values
> that are unique within the given repository; what is the primary key;
OK, let's say:
The "svn:author:authn-id" value is the primary key, and so is unique within a
[Subversion repository | Subversion server ?].
On 01/04/2012 01:42 PM, Julian Foad wrote:
A PROPOSAL FOR EXTENDED AUTHOR IDENTIFICATION
USE CASES
1.[This one I am aware of.]
A large company has authenticated user ids that are numeric. That means the "log" and
"blame" information shown by most Subversion clients is not easy to understa
On 04.01.2012 19:42, Julian Foad wrote:
> DESIGN
>
> The extended author fields are delivered through revision properties. The
> values are UTF-8 text. These revision properties are readable but not
> writable by clients.
>
> Three property names are initially designated as "well known":
>
This is great, Julian. It is pretty good for a draft. I'll get back to
you with the detailed answers tonight - just wanted to give my thumbs up.
I'm ok with a simpler solution that just sets the attributes on commit,
but what you have described looks like a good step up from the minimum
and so
Hi Mark.
I think I can see to some extent what you are getting at, but not clearly. We
all need a common frame of reference for understanding why and how some sort of
extended author information could be useful. To help us get there, I put
together the following tentative proposal to act as a
On 04.01.2012 13:50, Mark Mielke wrote:
> Branko: If "svn log", "svn blame", and anything like TortoiseSVN or
> Subclipse were to support this, you might have a point. As it is,
> anybody with teams large enough such that the unique identifier is not
> recognizable (i.e. committer A immediately rec
Branko: If "svn log", "svn blame", and anything like TortoiseSVN or
Subclipse were to support this, you might have a point. As it is,
anybody with teams large enough such that the unique identifier is not
recognizable (i.e. committer A immediately recognizes and knows that
unique identifier for
On 04.01.2012 11:09, Vincent Lefevre wrote:
> On 2012-01-03 15:44:47 +0100, Branko Čibej wrote:
>> I think this whole thread is slightly bogus. It should be obvious that
>> whatever is in the svn:author field has better be a unique identifier of
>> the person responsible for the commit, regardless
On 2012-01-03 15:44:47 +0100, Branko Čibej wrote:
> I think this whole thread is slightly bogus. It should be obvious that
> whatever is in the svn:author field has better be a unique identifier of
> the person responsible for the commit, regardless of how it gets there.
I'd say that this choice s
On Tue, Jan 03, 2012 at 12:53:39PM -0500, Mark Mielke wrote:
> 1) Require a means to reliably determine the AUTHOR of a changeset.
> Reliable here means machine consumable in a standard format which
> all tools are aware of because the standard is documented.
>
> 2) Require all native output from
On 01/03/2012 12:27 PM, Stefan Sperling wrote:
On Tue, Jan 03, 2012 at 12:11:20PM -0500, Mark Mielke wrote:
Other solutions provide these capabilities out of box.
Could you point out which solutions exist so people can take a look at them?
GIT, ClearCase, and Perforce are the ones I use.
GIT
On Tue, Jan 03, 2012 at 12:11:20PM -0500, Mark Mielke wrote:
> Other solutions provide these capabilities out of box.
Could you point out which solutions exist so people can take a look at them?
You can keep criticising us all you want, it won't change a thing
if you don't also explain in detail
FYI that "full name" or "email address" are not actually aspects of a
unique identifier. People's names change, and email addresses change.
The unique identifier should normally be much more persistent and should
enable cross referencing with other tools and database reports. The name
and email
To be blunt - this is exactly why Subversion will stay small. When the
main people on the developer list hold small world views such as "it is
the responsibility of the organization that uses Subversion to customize
the dozens of tools they integrate with in a non-standard way", it is
guarantee
On 03.01.2012 04:02, Stefan Fuhrmann wrote:
> * What is an author?
> * How do concepts like "account", "person",
> "role", "group" relate to that notion?
> * What aspects of the above can be provided to /
> handled by Subversion in a portable way?
> * What are typical use-cases and do they matc
On 02.01.2012 09:34, Mark Mielke wrote:
On 01/02/2012 02:52 AM, Alan Barrett wrote:
On Sun, 01 Jan 2012, Mark Mielke wrote:
Another idea is to change the revprop's value in the pre-commit or
post-commit hook: [...]
This is what we've been doing for about two years. It has the
consequence tha
On 01/02/2012 04:48 AM, Alan Barrett wrote:
On Mon, 02 Jan 2012, Mark Mielke wrote:
If your third party tools can't extract the unique ID from
svn:author = "Display Name " then perhaps the
problem lies at least as much in your third party tools as in
subversion.
I wonder if you thought this
On Mon, 02 Jan 2012, Mark Mielke wrote:
If your third party tools can't extract the unique ID from
svn:author = "Display Name " then perhaps the
problem lies at least as much in your third party tools as in
subversion.
I wonder if you thought this through before posting. :-)
You are saying t
On 01/02/2012 02:52 AM, Alan Barrett wrote:
On Sun, 01 Jan 2012, Mark Mielke wrote:
Another idea is to change the revprop's value in the pre-commit or
post-commit hook: [...]
This is what we've been doing for about two years. It has the
consequence that tools don't automatically match unique
On Sun, 01 Jan 2012, Mark Mielke wrote:
Another idea is to change the revprop's value in the pre-commit
or post-commit hook: [...]
This is what we've been doing for about two years. It has
the consequence that tools don't automatically match unique
identifier to commit as they no longer match
31 matches
Mail list logo
