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

Re: svn diff output

From: Ben Reser <ben_at_reser.org>
Date: 2004-09-16 07:43:35 CEST

On Wed, Sep 15, 2004 at 08:51:48PM -0500, Ben Collins-Sussman wrote:
> We also already have a patch-like representation of these tree deltas:
> it's our dump format. The dump format is meant to be portable, and has
> an RFC-822 "look and feel". Take a look at it. It may be 90% of what
> we need for defining this new patch format.
> It's documented here:
> http://svn.collab.net/repos/svn/trunk/notes/fs_dumprestore.txt
> The original versions 1 and 2 of this format always included full-texts
> of files. But ghudson introduced format version 3 in svn 1.1, which
> allows binary diffs instead of full-texts. That's a huge win.
> Is this a good starting point? Doesn't it seem like we're mostly there?

Basically I was thinking of something similar to feel of traditional
diffs, but that supported representing our full feature set. I think
the dump format doesn't really fit that bill. It's a fine format for
dumps and seems to be optimized to make a very fast parser (important
when loading large dumps).

We need something reasonably compact (even at the cost of parsing
difficulty), human readable (so it can serve the dual purpose of
displaying details on the changes and how to apply a changeset to the
wc/repo), and without binary diffs unless the file is clearly binary.

Binary diffs should probably be encoding to some format that is friendly
to email and text editors. Maybe BASE64 our svndiff format for them.

I do think the dump format points out exactly what functionality we need
to support.

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 16 07:44:29 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.