Re: [Gnu-arch-users] Some issues (why no bdiff for Arch)

[James Blackwell]

I'll handle these out of order, if you don't mind.

Matthieu Moy:
> Your claim is that backup != revision control. I also don't understand
> this.

Peaches and Oranges are both fruits. Both are round, orange inside, sweet
to the taste and grow on trees. But does that make a peach into an orange?
Of course not. 

However, lets pretend, in this particular case, that arch *is* a backup
system. Well, how do other backup systems perform? 

In Unixland, the defacto leader is tar with gzip, which *is* a backup
system. How does tar handle changed files? Well, there are two ways. You
can either "append files that are newer than those in the archive" to 
an existing archive, or you can make a new archive which only includes
files which are newer than a certain date. 

In simpler words, tar works in a similiar manner to how arch works in
its worse case scenerio.

However, unlike tar, arch's worse case scenario (the _only_ scenario for
tar) doesn't fit all files. It so happens that a common tool, called
patch, does a good job of seperating out changes from two versions of a
file. This property is *very* useful for programmers! As such, when arch
comes across text files, instead of just preserving a new copy of the
file, it preserves the changes in the file -- something that is very
useful to programmers.

Like peaches and oranges, arch (a revision control system) and tar (a
backup system) share certain similarities. But they're still not the
same thing. A backup system is most concerned with providing an older
copy of a file if the main one becomes corrupted. A revision control
system is most concerned with showing the changes of a file.

Yes, there are tools like xdelta, which are capable of producting binary
diffs. The resulting binary diffs, unlike patch's diffs, are useless
from a human readable perspective. So the only reason to implement
xdelta is to save disk space. 

Saving disk space is not one of Tom's priorities. He would probably care
more if he were designing games that included images, but apparently
he's not doing that. 

However, Tom has spoken on this and similiar issues, and he's
essentially said that he's willing to review high quality patches that
teach arch how to use xdelta. 

Personally, I think that's fair; Who should work on something they don't
personally care about unless their getting paid to do it?


Matthieu Moy:
> I have a powerpoint (:-/) presentation managed by arch. After a
> set of modifications, I write a log file and commit. When I make a
> mistake, I use "tla logs" to identify the revision I want to come back
> to. Then, "tla get", ... If I have to branch, I can use "tla tag", ...
> Off course, I can use only a subset of tla's feature, but why should I
> drop tla ? My presentation is in a project with other source files,
> why should I create a separate project not managed by revision
> control?

At this point, if disk space is a consideration, you're using the wrong
tool. Arch is designed to be a revision control system for programmers
that are coping with changes in source code. 



Matthieu Moy:
> There's something I don't understand. No one would reasonably propose
> a revision control system storing full copies for source ASCII files
> today. You could *off course* store a full copy for source files too.
> You would have merging algorithms, usually more effective than just
> storing the patch in the archive. That is clearly the *wrong*
> solution. How is that different from binary files?

This is exactly how backup systems like tar act. Considering how earlier
you said that arch is a backup system, why would you tolerate this
behavior for other backup systems but not for arch?

Matthieu Moy:
> My guess is that you never worked in an environment with people making
> heavy use of binary files. Isn't it?

Based on my poking around on his archive, no, he doesn't deal with
binary files in archives a whole lot. 

At this point in time, I would say that Tom is an expert in revision
control systems and not backup systems.

Matthieu Moy:
> I know I could rather easily create a wrapper around diff+xdelta, but
> you know as well as me that this would break the archive format
> compatibility. Once again, my claim is not that tla should be modified
> right now, but that 1) I would have liked to have it from the
> beginning (too late ! ;-) 2) If the archive format ever change, it
> should include a binary diff possibility.

Then I suggest you get working on a patch to arch that gives arch xdelta
support before the next time the archive format changes. :)

Matthieu Moy:
> There's a big difference between "We should have it, but it's not
> reasonable to implement it now" and "We don't have it and we made the
> right choice".

Sure there is. This is neither of those. This is "Sure! High quality
patches welcome"

-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400