|
From: | John A Meinel |
Subject: | Re: [Gnu-arch-users] Arch Versus CVS Versus Subversoin |
Date: | Sun, 05 Dec 2004 20:16:39 -0600 |
User-agent: | Mozilla Thunderbird 0.9 (Windows/20041103) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |