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

[Tom Lord]

    > From: Stefan Monnier <address@hidden>

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

I mean whole-tree queries over a tree with a very large number of
revisions -- simply because you'll wind up having to read the entire
history.


    >> 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've explained why a few times and I'll try again once more right now
but I'll leave off there.  I'm tired and cranky (nothing to do with
you -- just from schlepping lots of stuff between old and new
apartments, daily, with a number of more days of this to go :-).

Yes, archive cycling is an "extra step" in some situations.   Often
it's not really an extra step -- it's recording useful information
like milestones or significant time periods -- but certainly we can
imagine situations where it just happens at arbitrary times relative
to project flow.   It's interesting to me that it's hard to imagine
projects that are _well_managed_ that would fall in this category but
I won't rule out that some could exist.

But: the _scale_ at which you have to cycle archives to avoid any
kinds of performance problems is _already_ quite reasonable.   It's on
par with comparable kinds of "disruption" you experience with other
systems for other reasons.  It's no big deal.

In return for putting up with cycling, in those cases where it's just
arbitrary, you get a revision control system that's simple in
implementation, simple to administer, and that places very low demands
on servers.

I'm all ears for _simple_ changes to arch that raise the number of
revisions between times when cycling seems like a good idea for
performance reasons -- but I'm also satisfied that that number of
revisions is already quite reasonable.

-t