Re: [Gnu-arch-users] Some issues

[Tom Lord]

    > From: Matthieu Moy <address@hidden>

    > Florian Weimer <address@hidden> writes:

    >>> I think if you were careful not to prune logs from still-active
    >>> branches, sure.

    >> Uh-oh.  This needs a global view and thus is very hard to do.

Please see my recent message for a real solution.


    >> For GCC, this means that most patchlogs cannot be removed until the
    >> branch is officially dead (not only unmaintained, but really dead).
    >> Currently, GCC 3.2, 3.3, 3.4 and of course HEAD are still in
    >> development.  A sizable number of patch logs has to live for
    >> years.

In essense, my solution "compresses" long-lived very detailed branches
into less detailed (and better explained) branches.  For a long-lived
"logical branch" that has to live for years, you'd probably have a
long-lived low-commit rate narrative branch for it and, whenever you
really work on that branch, a short-lived, high-commit rate
integration branch for the logical branch.   The high-rate logs can be
pruned frequently -- they don't have to live for years.



    > Well:

    > 1) arch  needs a  solution about  this.  A text  file listing  patches
    >    present in the  tree, but for which the log  has been deleted would
    >    be a good solution.

Mine is better.


    > 2) However, your  problem has a solution without  modifying tla. Since
    >    tla makes branching easy, it is usually recommended to create a new
    >    branch for  each big feature you  want to develop.  Each branch may
    >    have a  big-but-not-huge number of  revisions, but the  main branch
    >    will mainly contain big  merges from the development branches. Once
    >    a feature  is stable  enough, seal the  branch, and after  a while,
    >    prune the patch-log.

That specifically doesn't apply to "the gcc problem".  They, in
effect, already have all the new features coming from (logical)
branches.   The problem is that they want to continuously integrate
most of these as they come in and there's no way around the fact that
that leads to a super-human commit rate.

-t