[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: Charles Acknin <charlesacknin_at_gmail.com>
Date: 2007-06-27 10:35:12 CEST

On 6/26/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> > 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).

I'll ensure it's clear.

> > 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?

That's not what I meant. In my view, the information shouldn't be
doubled/redundant, for size care reasons. I meant when deltas have to
be provided (that's the case with file addition IIRC and a few other
cases), we'll use svndiff1. The only unidiff that's in my design is
about contextual changes.

And yes, that would be a way easier implementation to consider
everything in unidiff text to be just a 'comment'.

> > 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?

How about "Hunk failed" here? And BTW, how often does the command set
happen to change?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 27 10:34:50 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.