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_at_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_at_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<mark_at_mielke.cc>
Received on 2012-01-02 20:09:44 CET