Re: [Gnu-arch-users] Fast commits

[Robin Farine]

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, 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?


Robin