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.
> 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.
> 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.
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.
--apb (Alan Barrett)
Received on 2012-01-02 10:49:03 CET