[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems with the documentation of Subversion dump format

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 30 Dec 2011 21:36:55 +0200

Mark Mielke wrote on Fri, Dec 30, 2011 at 14:24:25 -0500:
> On 12/29/2011 11:09 PM, Daniel Shahaf wrote:
>> Steinar Bang wrote on Thu, Dec 29, 2011 at 22:55:09 +0100:
>>> Couldn't you just store this information as custom properties? Even
>>> though svn isn't able to use it, at least the information would be
>>> preserved...?
>>>
>> Re "throw away the domains": svn:author properties be set to any
>> byte-string which is NUL-terminated UTF-8 that doesn't contain
>> (0x0D).
>
> 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.

</random thoughts>

> 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>
>
Received on 2011-12-30 20:37:38 CET

This is an archived mail posted to the Subversion Dev mailing list.