Re: [Gnu-arch-users] Arch Versus CVS Versus Subversoin

[John A Meinel]

Cameron Patrick wrote:
> Andre Kuehne wrote:
>
>
> > > Arch already has the only kind of binary diff that is possible.
> >
> > You consider "putting the original file and its replacement side by side"
> > a binary diff?
>
>
> For arch's purposes, it is isomorphic to the kind of "binary diff"
> that subversion uses (and for that matter, to every conceivable type
> of diff algorithm).  It is rarely the most the disc space efficient way
> of storing change but any changes to make arch use e.g. xdelta would
> merely be an implementation detail and not affect the user experience
> at all (except insofar as download times and archive storage space
> would be decreased).
>
> Cameron

It is a binary diff. But it isn't the "efficient binary diff" that is 
touted for SVN.

As far as xdelta being "merely an implementation detail" that isn't 
quite true. In the arch sense, xdelta/vdelta/whatever needs to know that 
it is patching the exact same file. So you need to have the "pre" to 
compare against. Now xdelta might store the md5sum or something like 
that of the previous file, and refuse to patch a different file.

But one thing you don't want is to replay someone else's patch-42 and 
get a completely corrupted binary file. You would much prefer a 
conflict. And if you get a conflict, for a binary file you'd probably 
prefer a full copy of the original as the reject (which I believe is 
what tla does now.)

Because a binary delta is relatively useless to humans.

It might be nicer if arch could store the pre and then the xdelta 
instead of storing both. Or maybe the post and an xdelta to go 
backwards. But for people asking the question "does arch support binary 
diff like SVN" they want us to store *only* the xdelta.

John
=:->

signature.asc
Description: OpenPGP digital signature