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

[Tom Lord]

    > From: Stefan Monnier <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}

    > Why?
    > It's not needed now and wouldn't been needed with my proposal either 
AFAICT.
    > Basically neither mkpatch nor dopatch would need to be changed...
    > weeellll:
    > 
    > The problems I can see with my approach are the following:
    > - Add patch-N-M to a tree that already has it: the new file's content
    >   should be the same, so it should be trivial to resolve the "conflict".
    >   This situation already exists, although my proposal might make it happen
    >   in a few new cases.
    > - remove patch-N (or patch-N-M) from a tree that doesn't have it.
    >   This situation also already exists, but now it gets a bit trickier
    >   because resolving the conflict can become less trivial since the tree
    >   might have patch-N "pruned" in patch-A-B, so we may have to take special
    >   steps to resolve such "remove an non-existing file" conflicts.
    > - remove patch-N (or patch-N-M) in a tree that does have it but that also
    >   has patch-A-B where N is between A and B.  Now, this is getting ugly
    >   because we have to figure out whether the removal of file patch-N
    >   is due to pruning (i.e. the patch is still present but in another file)
    >   or not in order to know whether we should also adjust patch-A-B (as well
    >   as any other patch file that contains N),

    > OK, well, still not completely trivial.

That's what I'm saying.   You're coming up with all these special case
rules for conflict resolution in your index files.  Well, screw that
entirely -- it works out more easily in the code to generate the index
files fresh.   

My variation on your basic idea reduces the impact on the
mkpatch/dopatch process.

The gist is: supplement the tree inventory (for mk/do-patch purposes)
with the contents of the index file.   Make mk/do-patch cope cleanly
with log files in the index but not actually there in the tree.   At
the end of dopatch, dopatch has an index for the new tree -- just
write the subset of that that is log files to generate the new index
file.

Try it.  It's fairly clean.  There's still interactions with other
commands to work out but this part of the core idea comes out clean
(and cleaner than special case conflict-resolution rules for the
internals of patch-logs).


------
that being said:
------

The _other_ potentially clean approach that occured to me involved
patching index files using set operations rather than textual diffs:
in essense, substituting a `join' application for `patch'.

This is weirder, though, because -- with the first idea your
essentially simulating operations on patch log files that might not
really be there, and writing the result of the simulated operations.

With this `join'-based idea your just doing something that you hope
you've correctly proven is isomorphic to the simulation you're
avoiding.

-t