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 committer B) needs to FUDGE svn:author to include
additional information which is not really part of the unique identifier
at all and is only a humanly representable version of the unique
identifier, and this leads to:
1) Breakage in other tools. Committer mappings don't work.
2) The unique identifier is now not correct as it includes non-unique,
non-permanent details that change.
But now I'm repeating myself. I think the problem here is that people
are theorizing about subjects that they have not had to deal with real
life problems for. Theory vs practice. You can say that Enterprise like
to repeat things - but I'm not sure you understand what Enterprise is
doing... it just looks like repeating to you, and so you assume it has
no purpose, and therefore no merit.
On 01/04/2012 05:35 AM, Branko Čibej wrote:
> 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 of how it gets there.
>> I'd say that this choice should entirely be made by the administrator
>> of the repository.
> Exactly. And we give that choice, at least for Apache-embedded servers
> (which is what enterprises will use, I hope).
>
> If we, say, added another property where admins could write a whole
> other set of information, we'd either have to define the format (and
> incidentally tee off the 90% who want a different format), or leave the
> contents up to the administrator (and tee off the other 90% who want
> compatibility across diverse installations).
>
> I still don't understand why it's so hard for other tools to, e.g., look
> up the svn:author unique ID on an LDAP server somewhere. Otherwise we're
> effectively duplicating (a small part of) any of the "standard"
> directory services.
>
> (Yeah, I know that "enterprise" tools like to duplicate functionality
> and mess up open standards while they're at it, but I don't see why we
> should be doing the same.)
>
> -- Brane
--
Mark Mielke<mark_at_mielke.cc>
Received on 2012-01-04 13:50:44 CET