Re: [PATCHv2] Add details about svn-fe's dumpfile parsing

From: Andrew Sayers <andrew-git@pileofstuff.org>
Date: Apr 16, 2012, 22:15 UTC
Message-ID: <4F8C9A13.80906@pileofstuff.org>
In-Reply-To: <20120416213910.GP12613@burratino>

On 16/04/12 22:39, Jonathan Nieder wrote:

Show 12 quoted lines

> Andrew Sayers wrote:
> 
>> The dumpfile documentation says that "... property key/value pairs may
>> be interpreted as binary data in any encoding by client tools"[1], but
>> SVN itself interprets the data as UTF-8
> 
> Yes, I suspect most of the changes you proposed for the INPUT FORMAT
> section would actually be better as changes for the
> dump-load-format.txt document.  I imagine that folks on the dev@ list
> might be able to clarify a few details (e.g., what one is expected to
> do with historical repositories with non-UTF-8 property data), too.
> What do you think?

Hmm, I'd personally be more interested in going to the SVN folks with a more general question. The SVN Book[1] says "pathnames can contain only legal XML (1.0) characters, and properties are further limited to ASCII characters. Subversion also prohibits TAB, CR, and LF characters in path names". Code documentation[2] gives a lot of complex rules that don't bear much resemblance to the behaviour I've seen so far (albeit only lightly tested in SVN 1.6). The dumpfile docs[3] pretty much declare a free-for-all, and I've yet to see historical documentation properly written up anywhere.

I guess my question would be something like "what should a client reading or writing SVN dumps do to stay as compatible as possible?", but I feel like I've got a collection of bits that haven't quite coalesced well enough yet to really drive the conversation.

As a web developer, the SBL work I've been doing is starting to remind me of the jump from HTML4 ("here's what clients should do. Of course it's not what they actually do...") to HTML5 ("here's what clients actually do. No we're not allowed to just shoot those people"). Like HTML5, I figure I've got to take the argument to the official body some day, but I'd rather have something vaguely mature first.

My instinct is to put this on the TODO list for after I've finished writing tests, but I'm open to suggestions.

	- Andrew

[1]http://svnbook.red-bean.com/en/1.7/svn.tour.importing.html#svn.tour.importing.naming [2]http://subversion.apache.org/docs/api/latest/group__svn__fs__directories.html#details [3]http://svn.apache.org/repos/asf/subversion/trunk/notes/dump-load-format.txt