Re: augmented diff design patch format

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.
>
> I HISTORY
> -------
>
> [remind the reasons behind the design of such a new format]
>
>
> II DIFF SUBCOMMAND FORMATS
> -----------------------
>
> 'svn diff' subcommand is provided with 3 formats:
> * default: useful for code reviewing
> * unidiff: fits better towards patch(1) use
> * svnpatch: supports any change
>
>
> III SVNPATCH FORMAT
> ---------------
>
> 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
discussion.

Regards,
Malcolm