On 12/30/2011 02:36 PM, Daniel Shahaf wrote:
> Mark Mielke wrote on Fri, Dec 30, 2011 at 14:24:25 -0500:
>
>> With the caveat being that tools that assume that svn:author was set by
>> the Subversion API may no longer recognize the author...
> "by the Subversion API" isn't the right phrase, but anyway: by default
> the svn:author properties are set to the authenticated username (when
> such is available) and cannot be changed unless the administrator runs
> either 'svnadmin' or installs a pre-revprop-change hook.
>
> There's nothing preventing people from having, say, spaces in their
> usernames. So clients should cope with that.
>
> There is also nothing preventing people from having newlines in their
> usernames... but now, the fact the library would allow this doesn't mean
> it's a good idea to do this.
I think you are not understanding my concern. If svn:author is only ever
displayed to the user - then "authenticated username" may not be a
desirable form to use. For teams of 10 people, sure you can recognize
the uid of everybody in the team. But what about teams of 100, or teams
of 1000?
The Subversion documentation does not define any structure for this
attribute, therefore tools either assume that the Subversion API (or SDK
or whatever you want to call it...) initiated it to the authenticated
username. Some of them display this "as is". Some expand it using user
databases such as LDAP. Everybody does it different. This is a problem.
If you use a tool that doesn't know about other databases (such as "svn
log"), then it only shows the uid. If you work around this by including
structure in svn:author, because there is no standard, chances are that
no other tool will understand what you are doing, and it will break
mappings. For example - in Crucible/FishEye - it won't know who to
associate the commit with, so that when I login I can see my commit
history. Instead, I have to manually define mappings.
In any case - this is just yet another example of how Subversion really
doesn't scale. That it still can't properly merge across branches or
renames is much more important...
>> We're still being hit by this, but choosing to take this hit. Our
>> identifiers are not easily legible ("1234567"), so we translate
>> svn:author to "Full Name (GID)" format during commit. Tools such as
>> Crucible/FishEye can sort of work with this via the committer mappings.
>>
>> Just mentioning as I think the "svn:author" being one arbitrary
>> byte-string with no specification defining how structure can be added in
>> a portable way that tools should understand and support means that it
>> really isn't that flexible. It is a compromise.
>>
>> In the case of GIT -> SVN, the retaining of the information could be a
>> valid compromise. But it is still a loss of information, at least as far
>> as how tools such as Crucible/FishEye might interpret the content.
>>
>> --
>> Mark Mielke<mark_at_mielke.cc>
>>
--
Mark Mielke<mark_at_mielke.cc>
Received on 2011-12-31 02:23:25 CET