Re: [Gnu-arch-users] Re: Working out a branching scheme [was: tag --seal --fix]

[Stefan Monnier]

>> I don't assume a short period of time (I'm thinking of the Emacs
>> repository which is almost 10 years old (if you count its RCS
>> life)).  With CVS, the >10K revisions all in "the same big
>> thing" work just fine.

> I disagree that CVS works "just fine".  Just as with arch, there are
> some operations that work "just fine" in this case and others that
> don't.

Well, of course.  Otherwise I wouldn't be using Arch now, would I? ;-)
But what I meant is that "the performance of the most common interactive
tasks" is not noticeably worse than on a repository with only 100 revs.

> One trivial example of an operation that doesn't work "just fine" at
> this scale with CVS is the initial mirroring of a CVS repository (as
> in doing a first fetch of the GCC repository).   I wind up having to

I expect that this is the least of your problem.

> I'm sure that there are query operations on CVS that will be
> problematic.

You mean in general or specifically when you have 10K revs?
I can't think of any CVS query (status, annotate, -n update, diff, log, what
else?) which is noticeably worse with 10K revs than with 100 revs in your
tree.  Maybe `cvs log' if you don't specify a particular range of revisions,
but that's inherent in the semantics of the operation.

> A lot of your thinking here seems to be premised on the idea that
> archive cycling is bad .... to be avoided .... that the fact you might
> want to cycle an arch archive makes arch somehow worse than CVS.

The ability to do archive cycling and things like that is obviously
a strength of Arch, but I can't think of any reason why you'd consider it
good that archive-cycling might be *necessary* (i.e. imposed on the user)
to maintain good performance of common interactive tasks.

> I think such concerns are misplaced.

My goal is to make Arch easier to use, so that people can use it whichever
way suits them, even if it might seem (or even be) a stupid way to go
about it.  Currently Arch is pretty self-righteous in some respects (the
namespace being the most obvious one) and I'd like to see this reduced.

To put it another way, I think your implicit statement that "users should do
archive-cycling anyway" is similar to the attitude of some CVS-ers saying
"if you're moving things around a lot, your process is messed up".

>> Nobody has had to figure out some good split into sub-trees or to try and
>> cut the development into several versions (and the associated need to tell
>> the world where the new head of the trunk is to be found and to switch
>> their checked out tree to that new branch).
> In the past year or so of GCC development, alternative CVS mirrors
> have appeared because of other kinds of scaling difficulties CVS has.
> The commands needed to access Savannah repositories have changed.
> Every few months in GCC new tags are created and many developers have
> to adjust their trees for that.
> Archive cycling is no more intrusive than any of those operations.

And AFAIK, nobody was particularly happy about having to do that.

>> I never use `tla revisions', so I don't see why that would be a
>> problem.  What would a user use it for?
> I use it all the time to see what has changed recently and to help
> with merging.

Sounds like the wrong tool:
- it might fail to show you recent changes before the current branch's base.
- it will show also you all the non-recent changes on the current branch.
  worse yet: it'll first show you the non-recent ones and will only
  get to the recent ones at the end.

> I guess I also left out there the issue of mirroring.  If you're
> working on the head revision, a mirror is very handy but a history of
> 11k past commits is usually not.

I consider it as a limitation in the mirroring ability of tla: it should
be able to mirror only part of branch (like the N latest revs).
Also I agree with Aaron that caching patches would reduce the need
for mirroring.

>> Sometimes it is a very natural step because it's related to the
>> use of branches, but imposing it because of implementation
>> limitations seems just unfortunate.
> One can impose it just to keep the "unit of manipulation" of the
> history data in "human scale chunks".

But this "human" argument only makes sense if the human can't happily
handle the larger chunks.  Also it requires action on the human side to
maintain things humanly-manageable, whereas I'd like tla to automatically
(without user involvement) maintain things humanly-manageable.

> One simply can not do both short of making an implementation so hairy and
> so expensive to administer or so flakey as to be worse-than-useless in
> many situations.

Don't worry: I value the clean design of tla.  So, I'm quite willing to live
with things like archive-cycling, but I'd like it to be recognized as
"something we'd like to make unnecessary (though still possible and
desirable of course, but not indispensable) when we can figure out how to do
it cleanly".


        Stefan