[Top][All Lists]

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

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

From: Stefan Monnier
Subject: [Gnu-arch-users] Re: Working out a branching scheme [was: tag --seal --fix]
Date: 02 Apr 2004 15:56:41 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>> After all, we want to be better than CVS rather than worse, right?
> No, that's The Other Guys.   We want to make the hands-down-best
> revision control system.   Not quite the same thing.

Well, anybody who has used CVS on a long-term project may find it really
odd and annoying to have to cycle archives every once in a blue moon
because otherwise things get slow.  So they potentially won't find it to
be "the best" and definitely not "hands down".

> A total history containing 11K revisions is no sweat for arch.  A
> total history containing 100K revisions is no sweat.  Putting all
> those revisions in a single arch version?  You're moving into the area
> of using arch poorly.

Is there a fundamental reason why this is poor use?
I agree that it's a poor use of tla-1.2, but is it a poor use of Arch?
I tend to hope that it's a limitation of the current code since other
systems seem to be able to handle such situations without any
particular trouble.  Admittedly, the representation used by CVS makes it
much easier to deal with such cases, but isn't there some way to make an
Arch implementation that would still behave reasonably well with 100K
revs in a single version?
It seems like at least commit should not care about how many revs there are
since it should only care about the last few ones.

> 11k revisions in a year comes out to a bit more than one per hour, 24
> hours a day, 365.25 days.

What's up with years?  I don't think of my development in terms of years
at all.  It seems completely arbitrary, just designed to work around
tla's limitations.

> No development process that is doing that in a single arch version is
> doing anything useful.  (A process doing that across a few (coallescing)
> branches, on the other hand, is entirely realistic.)

No, it might very well be all linear progress with no big milestone of
any kind.  The eXtreme Programming style for example recommands an
evolutionary approach to software and some people (myself included) tend to
work in such a way that changes are brought in progressively such that each
step can be checked independently by third parties.


reply via email to

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