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

[Stefan Monnier]

>>> 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?
> There's fundamental reasons why it's poor use if all those changes
> take place over a short-enough time period (say, a year or 16 months)
> and if the tree is "one big thing" rather than something that could
> reasonably be broken-up into sub-categories.  Basically you have some

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

> tree that's changing at that rate and, at that rate, nobody working on
> or with the tree can really keep up with the changes.   It's the "dog
> pile on the mainline" technique.   The fundamental problems here are
> from the user perspective -- you're not using the tool to do something
> useful.

Ahem, I do consider Emacs to be useful and I do consider the use of CVS to
have been very useful for Emacs's development.

> There's a user-fundamental reason why it's poor idea if the project
> can reasonably be split-up into sub-categories or if all these
> revisions take place over many years.   Do you really want "tla
> revisions -s" (for example) to list 11k commits?

I never use `tla revisions', so I don't see why that would be a problem.
What would a user use it for?

> Finally, there's a tool-design fundamental reason why you don't want
> things that big.  Sure, 100k same-version-commits can be done, but
> only at the cost of a big leap in implementation complexity.   If
> there's no compelling use-case reason to want this -- why pay the
> costs associated with writing, maintaining, and administrating a more
> complex tool, especially when such a simple alternative is achievable?

OK, so you mean the problem is just an implementation limitation.
I can definitely live with that answer much better than with explanations
of how it would be wrong to even think of using a tool that way.

As you probably know I just consider archive-cycling to be fundamentally
wrong from the user's point of view.  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.

I understand the need for archive-cycling from an implementation point of
view, but I think it should be made as transparent as possible from the
user's point of view.  Maybe the answer is just to make `config's more user
friendly since their additional level of indirection can be used to
hide things like archive-cycling (the archive-cycling could then even
happen automatically every 1k revisions).

I have several times used Emacs's revision history to get `annotate' and
`diff' info dating back to very long ago.  So if we have to add some
archive/branch/version boundary along the way every year or so, it's very
important that tools like `annotate' are able to ignore those boundaries.

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

> I think an XP debate is straying off-topic but, if you're using XP:

I only meant to mention it as an example of a coding style that encourages
development with no revolution and thus with no natural version-boundary.

> Small commit rate but huge total number of revisions?   Ok, we're

Rate is irrelevant.  Tla's performance depends on the number of revisions,
not their rate.


        Stefan