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

[Bruce Stephens]

John A Meinel <address@hidden> writes:

> Bruce Stephens wrote:

[...]

> 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.

Very much so, yes.

> 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.

Indeed.  I've read comments by people who just don't care about
history beyond a few months, and that seems reasonable for some
environments.  

But at work we regularly want to look at code several years old and
fix problems people are having with it, and often that involves
applying some set of patches (because we've fixed it in the current
branch) to the old code.  (Of course, that doesn't require annotate
(I've also very rarely used annotate), but it almost always requires
looking at the code of various revisions.  Better than annotate would
be some function-based annotation tool (showing where some function
had been changed), as promised by some of the papers in the Stellation
project, but the code that's available doesn't yet do that.)

Presumably that's not an uncommon environment: the Debian security
team often backports bugfixes rather than upgrading packages.  I'm not
saying they're desperate for a dancy version control system, but that
seems like the kind of activity that's worth supporting: partly that's
star-merge and cherrypicking and things, but partly it's providing
ways of looking at old code and exploring changes in it.

> It is possible to make both fast.

Absolutely, yes.

> 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.

A new wire protocol isn't absolutely required, just some kind of a
smart revision library that can produce file revisions (and probably
other things you want from the revision library like diffs and
annotated files and things).  

On the other hand, once you've got that then you can reconstruct the
archive, so an obvious option is to regard the revision library as
primary, and generate the archive as necessary (indeed, Tom has
suggested that kind of thing as a potentially interesting experiment).