subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Mielke <>
Subject Re: format of svn:author
Date Mon, 02 Jan 2012 19:09:03 GMT
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 <uniqueid@domain>" 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 that if I make up an essentially arbitrary scheme, 
>> such as "Display Name <uniqueid@domain>", and you have a tool which 
>> is unaware of my scheme, and therefore your tool fails to matches 
>> users in the region because of my scheme - that your tool has the 
>> problem?
> It's a free text field, although it's probably a bad idea to put more 
> than one line of text there.  As the administrator who sets up the svn 
> repository, you are responsible for choosing what text you put in 
> svn:author.  If, as you said, you have tools that want to be able to 
> map it to a a more restricted type, such as a login name, or employee 
> number, or (part of) an email address, then the tool is responsible 
> for performing the mapping.  If the tool can't perform the mapping 
> then, yes, I say that the tool is incompatible with the way the 
> repository administrator has chosen to use the svn:author field.

No. I don't control the hundreds of tools that support Subversion. The 
tools cannot be responsible for conventions they are unaware of. I think 
you are thinking of the tiny little scope where the only components in 
the system are Subversion itself and tools that I (or you) are directly 
responsible for and have the power to change. This is an extremely small 
view of the problem.

>> Otherwise, only extremely casual interpretation can be done of the 
>> field. For example, it can be treated as a unique identifier - but 
>> more like a "foreign key" unique identifier in the sense that it is a 
>> key in some domain, but not necessarily a domain I know about or am 
>> an authority for.
> As the administrator who sets up the svn repository, and the hooks 
> that edit or validate the data as it goes into the svn:author field, 
> you have absolute control over the data format, so it's not fair to 
> say that it's in a domain that you don't know about -- It's in a 
> domain that you choose.  Whatever format you choose, you should make 
> sure your other tools can deal with it.

Only in the extremely small view that I describe above. So not really 
relevant to the real requirements.

>> Our exact compromise for the last three years is:
>> 1) original svn:author value arrives on the server as as "1234567" - 
>> a corporate unique identifier
>> 2) pre-commit re-writes svn:author to "Full Name (<original 
>> svn:author value>)"
>> 3) pre-commit adds <company>:gid as "<original svn:author value>"
>> Then as I mention - various other tools such as FishEye have explicit 
>> mappings from "Mark Mielke (1234567)" => "1234567" for each 
>> Subversion repository. We're primarily a ClearCase and Perforce shop 
>> right now - but even so, I have several Subversion repository 
>> mappings of this form. It works. It just sucks.
> If FishEye needs a huge mapping table from "text as it appears in 
> svn:author" to "unique id", with a row in the table for every possible 
> ID, then this process will be very painful for you; on the other hand, 
> if you could configure FishEye to extract the "1234567" from "Mark 
> Mielke (1234567)" using a regular expression or other string 
> manipulation technique, then it would be much more maintainable.

It is not reasonable for a Subversion user to customize every tool they 
use. It is far preferred for Subversion to provide the solution as a 
core function.

> I expect that changes on the subversion side could help (as you have 
> mentioned, adding more properties, or clearly documenting one or more 
> suggested ways of providing structure inside svn:author, or both), but 
> I still hold the opinion that your pain is caused at least as much by 
> FishEye as by svn.

More than help. It is the only true solution. Anything else - such as 
each Subversion user customizing their own tools - is entirely a hack.

Mark Mielke<>

View raw message