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.
>
> I HISTORY
> -------
>
> [remind the reasons behind the design of such a new format]
>
> (We want something that supports any change and suitable enough for code
> review.)
>
>
> II SVNPATCH FORMAT IN A NUTSHELL
> -----------------------------
>
> 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?
--ben
---------------------------------------------------------------------
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