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

Re: augmented diff, draft now mature

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2007-07-04 17:47:19 CEST

On Tue, Jul 03, 2007 at 08:06:52PM +0200, Charles Acknin wrote:
> I've wrote some more in the draft. I think it has come to a mature
> state now (part I excluded), it should be a solid basis to go on, and
> I want to make sure we reach consensus with this statement. (I tried
> to aggregate as much as possible advises I collected from the previous
> post.)
> 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]
> (We want something that supports any change and suitable enough for code
> review.)
> -----------------------------
> 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 (ra_svn), gzip'ed,
> base64-encoded

Rather than comment point-by-point:

I don't think there are significant advantages to making the
computer-readable portion gratuitously not human readable. For example,
what if the non-diff operations were described as svn command-line commands?

We already have an evaluator for those, too (we would need to add an
encoder and tokenizer, though).

# svn mv path/to/file path/to/newfile

The above syntax looks pretty good to me. It's tweakable, reviewable,
and extremely well documented. Also, it's tolerant of revision skew
between WCs.

Finally, people with older clients can pipe it through "cut -c2- | bash".

Is there a drawback to this approach that I'm missing?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 17:47:52 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.