Re: [Gnu-arch-users] Fast commits

[Tom Lord]

    > From: Robin Farine <address@hidden>

    > Tom Lord wrote:

    > >Yup.  There's no rocket science here.  We can prune and perhaps
    > >restore in very automatable and handy ways (dozens of lines of new
    > >code).  But it's kind of a chicken-and-egg problem from my
    > >perspective, at the moment ---  I kind of want to run head-on into the
    > >theoretical problem first hand before I pick the dozens of lines of
    > >code needed to solve it.

    > Not very theoretical and you probably already considered a similar 
    > alternative, 

Actually, no, I hadn't.

    > but I just wonder whether this could work without adding 
    > too much complexity and avoid the need for log pruning.

    > Currently, we have {arch}/<p>/.../patch-log/<logK> where <logK> contains 
    > the complete log message for the change set. This causes the computation 
    > time of a change set to increase proportionally to the number of patch 
    > logs in the version.

    > Let us suppose we replace the patch-log directory with three files. One 
    > for applied patches from this version, a second that lists continuations 
    > and a third containing the full log text of the last revision.

    > The format of the first files could be a sequence of patch numbers or 
    > intervals of patch numbers:
    > 
    >     [p0,pK], pK+2, [pK+4,pL],...

    > The second file contains a sequence of key - value pairs for 
    > continuation (tag) revisions

    >     0: <archive>/<project>--<branch>--<version>--<patch>
    >     ...

    > The third file contains the full log message of the last patch, thus 
    > getting the log message of an anterior revision would require an access 
    > to the archive or to a revision library. But I assume it would not 
    > happen during commit or merge operations.

    > Agreed, the handling of these files would probably not be as simple as 
    > it is currently for the patch logs but it does not seem to be extremely 
    > complex either.

    > Does something like this deserve some more thoughts for a future version 
    > of the archive/working dir formats?

It's a very promising idea in general terms (ignoring inessential
details of what you are describing).  It would need more thought about
what exactly goes into the summary files you are describing, how they
will be managed to avoid lossage, how they interact with changeset
computation and application, and how that will impact various forms of
query.  Plus the things on top of those that I'm forgetting right now.

One additional thought is to combine it with a revised auto-ChangeLog
mechanism (so more log texts are conveniently preserved) and enable
some kind of per-tree ChangeLog pruning rules to be established.

(This is one of the freshest and most interesting ideas for core-arch
that I've seen in a _long_ time.)

-t