On 04.01.2012 13:50, Mark Mielke wrote:
> 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.
I understand all this, but how do you propose that, e.g., "svn blame"
would guess /which/ of the alternative identification tokens it's
supposed to show? If you don't want to always show the unique ID, then
obviously you'd choose one of the alternatives based on ... what? The
identity of the invoker of the command? Some other criterion? Things
quickly become horribly hairy.
Without specific use cases and examples, it's hard to come up with any
kind of coherent identification scheme that's different from what we
have now.
-- Brane
Received on 2012-01-04 15:44:27 CET