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<m...@mielke.cc>
