Message-ID: <41B3C107.5060908@arbash-meinel.com>
Date: Sun, 05 Dec 2004 20:16:39 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Cameron Patrick <cameron@patrick.wattle.id.au>
Subject: Re: [Gnu-arch-users] Arch Versus CVS Versus Subversoin
References: <20041205000613.PNEI7152.lakermmtao09.cox.net@nonerjsnum1tkq>	<26E1F314-4654-11D9-AD55-000A957659CC@spy.net>	<20041205023828.GA11443@suffields.me.uk>	<20041206015353.GA7353@aku>
	<20041206020747.GA6983@patrick.wattle.id.au>
In-Reply-To: <20041206020747.GA6983@patrick.wattle.id.au>
Cc: gnu-arch-users@gnu.org
Precedence: list
Content-Type: multipart/mixed; boundary="===============0701248359=="
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 3092
Lines: 90
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0701248359==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig27A453061BFDE4B812352C55"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig27A453061BFDE4B812352C55
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
=:->

--------------enig27A453061BFDE4B812352C55
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBs8EHJdeBCYSNAAMRAr9WAKDV5gUWuaByfV4YQH3sHZVJdic2gwCffbNw
ZPvNcNanE5VJN3AXIgnPq5M=
=gg+N
-----END PGP SIGNATURE-----

--------------enig27A453061BFDE4B812352C55--


--===============0701248359==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
--===============0701248359==--