git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Sayers <andrew-git@pileofstuff.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	David Barr <davidbarr@google.com>,
	Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCHv2] Add details about svn-fe's dumpfile parsing
Date: Mon, 16 Apr 2012 23:15:47 +0100	[thread overview]
Message-ID: <4F8C9A13.80906@pileofstuff.org> (raw)
In-Reply-To: <20120416213910.GP12613@burratino>

On 16/04/12 22:39, Jonathan Nieder wrote:
> 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

  reply	other threads:[~2012-04-16 22:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-15 16:10 [PATCHv2] Add details about svn-fe's dumpfile parsing Andrew Sayers
2012-04-16 20:06 ` Junio C Hamano
2012-04-16 21:35   ` Andrew Sayers
2012-04-16 21:39     ` Jonathan Nieder
2012-04-16 22:15       ` Andrew Sayers [this message]
2012-04-16 22:27         ` Jonathan Nieder
2012-07-23  1:37       ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F8C9A13.80906@pileofstuff.org \
    --to=andrew-git@pileofstuff.org \
    --cc=artagnon@gmail.com \
    --cc=davidbarr@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).