Re: [Gnu-arch-users] Re: Fast commits

[Tom Lord]

    > From: Miles Bader <address@hidden>

    >> I think the answer lies in redundancy: the current structure with
    >> {arch}/.../patch-log/patch-N files would work just as before.
    >> But we could also represent the same info with file with names
    >> {arch}/.../patch-log/patch-N-M.

    > Hmmm, that's clever....

This might work out pretty cleanly.

In essense, mkpatch and dopatch would:

1) maintain an index file of the virtual patch-log contents under
   {arch}

2) be tolerent of patch logs found in the index but not actually
   there.  For example, if the _index_ for tree A has patch-N but
   tree B lacks it, and both trees are missing the actual patch-N
   file, mkpatch would still record a delete of the missing file.

   Similarly, dopatch would have to be able to _add_ a patch-N file
   to the index even if the changeset doesn't actually include the
   patch-N file (but only indicates that it has been added).

3) never patch the index file directly.   dopatch already keeps
   track of the inventory of the "resulting tree" internally.
   Just write the index file fresh at the conclusion of dopatch.


    > In the recent discussion on this list, of `batched' patch-logs with
    > user-driven batching, the question of what do about overlaps (between 
batched
    > and non-batched, and overlapping batch ranges) didn't really come up; I 
think
    > the presumption was that nobody batches up patch-logs that are recent 
enough
    > to likely cause conflicts, and that the batching commands would handle
    > removing duplicates at batching time.  But as you say, the immutable 
nature
    > of patch-logs means that really, overlap is no problem.

    > In that discussion, something like .tar.gz files were used for batching
    > (patch-logs respond really well to lz compression); presumably the
    > `impossibleness' of conflicts means that using binary files is no problem 
in
    > this context (diff will always just return either file-the-same, or
    > new/old-file-doesn't-exist)...?

Bundling and compressing logs would then be a separate thing.  It's
considerably more tedious to do well.

-t