[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John A Meinel
Subject: Re: [Gnu-arch-users] Re: Arch Versus CVS Versus Subversoin
Date: Mon, 06 Dec 2004 16:33:37 -0600
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Bruce Stephens wrote:
Charles Duffy <address@hidden> writes:

Losing dumb server support seems a bit much to pay for such a
generally unimportant feature.

Storing binary files more compactly seems pretty unimportant, I agree
(well, it seems unimportant to me).

Storing text files in such a way that they can be retrieved
efficiently seems more valuable---so valuable that we're willing to
store multiple revisions in plain text.

I think it's at least possible that per-file things (such as "cvs
annotate" and the like) are more commonly used than things like
star-merge, and so a version control system implementation that
optimised those (and made things like star-merge less efficient) might
be a better fit for what people use version control systems for.

You wouldn't need to lose dumb server support---there'd be nothing
stopping an implementation also producing and reading Arch archives.
Indeed, this xdelta storage of revisions could simply be a more
compact revision library implementation---that would surely be

Actually, on the arch-dev list we discussed quite a bit how the current archive format could easily support faster annotations. And I have to say, it depends on your usage.

I have never used annotate seriously (only, hey that's kind of neat), but I've run star-merge at least hundreds of times. For some people the opposite would be true.

It is possible to make both fast.

Trying to create a server that used xdelta internally would be a little bit painful, but you are completely right, it would be possible. Just not really worth creating a new wire protocol, and all the rest of the headaches.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]