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

Re: augmented diff design patch format

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-06-26 12:21:24 CEST

On Fri, Jun 22, 2007 at 09:45:34PM +0200, Charles Acknin wrote:
> I'm not done yet writing the design document regarding the patch
> format but here's attached a first draft. I'd like to get a feedback,
> especially on the sole use of svndiff1 (line 32) within the patch. I
> don't think this turns to be an issue as a client will need the svn
> patch subcommand to apply the patch anyway, which implies a fresh
> client release (at least post 1.4.x), which implies svndiff1
> capability.
> As for the implementation, I'll be able to use some existing code to
> parse subversion protocol bytes. Though, I'm planning to tweak the
> code to fit with such an offline/one-way use (no negotiation, no
> response, restrict to the editor command set, so forth). svn patch
> would just read svn protocol bytes out from the patch, and drive the
> client's editor from that. Should anyone have a better idea instead
> of or to enhance this one, I'd be glad to hear and work it out :-)
> I'm working on a python test in parallel, soon coming.
> Cheers,
> Charles

> This file documents the 'svnpatch' format that's used with both diff and patch
> subcommands.
> -------
> [remind the reasons behind the design of such a new format]
> -----------------------
> 'svn diff' subcommand is provided with 3 formats:
> * default: useful for code reviewing
> * unidiff: fits better towards patch(1) use
> * svnpatch: supports any change
> ---------------
> First off, let's define it. svnpatch format is made of two ordered parts:
> * (a) human-readable: made of unidiff bytes
> * (b) computer-readable: made of svn protocol bytes, gzip'ed, base64-encoded

(You're actually referring to the ra_svn protocol here, which took me a
minute or two to understand).

> But, as we're not in a client/server configuration:
> - (b) only uses svn protocol's Editor Command Set, there's no need for the
> Main Command Set nor the Report Command Set
> - a client reads Editor Commands from the patch, i.e. the patch silently
> drives the client's editor
> - the only direction the information takes is from the patch to the client
> - svndiff1 is solely used instead of being able to choose between svndiff1
> and svndiff0

So, just so I'm clear, you're providing deltas here in addition to the
unidiff text at the start of the patch? (In fact, the unidiff is
effectively just a 'comment' as far as 'svn patch' is concerned, right?

> Such a format can be seen as a subset of svn protocol which:
> - Capabilities and Edit Pipelining have nothing to do with as we can't adjust
> once the patch is rock-hard written in the file nor negotiate anything
> - commands are restricted to the Editor Command Set

What happens when we extend the command set? In our current
client-server communication, we just pass back 'unsupported command' and
let the client (or server) decide what to do. Will we just fail to
apply a patch in that case?

> more, the following table compares what each format outputs against each
> operation:

I think that you should probably focus on svnpatch for the minute;
providing separate unidiff/default modes seems like a separate


  • application/pgp-signature attachment: stored
Received on Tue Jun 26 12:21:15 2007

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.