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

[Robin Farine]

Stefan Monnier wrote:

> 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.
>  
Would not three patch log files like

        patch-3
        patch-5-10
        patch-12


be equivalent with respect to mkpatch & dopatch to have a single 
summary file containing lines such as

        3
        5-10
        12


In both cases, the same problem arises. In the situation where we have a 
working tree based on version Vc that contains patch logs for versions 
Vp (the example above) and Vq. The patch log for Vp in Vq--Pk-1 looks 
like this (in multiple file format):

        patch-3
        patch-5
        patch-7
        patch-9-10
        patch-12


and the patch log for Vp in Vq--Pk (in summary format):

        3
        5
        9-10
        12


We cherry-pick patch-Pk from Vq (which removes Vp--patch-7) to apply it 
in our tree based on Vc. The change set for Vq--Pk-1 -> Vq--Pk would 
instruct dopatch to remove file {arch}/.../Vp/patch-7. Or, in the case 
of the summary format, we would have a standard diff that removes the 
line containing '7' from the patch summary for Vp.

If we now try to apply this change set to our tree, it would fail in 
both cases since patch-7 is not explicitly there. A file (patch-5-10) or 
an interval (5-10) has to be split before we can apply the change set.

Thus, I think that in both cases, we need some additional pre-processing 
& post-processing in dopatch/mkpatch that would deal with splitting or 
merging consecutive patch logs.

Assuming the above is correct, i.e. that the processing is equivalent 
for both representations, I believe that the summary file format has the 
advantage of minimizing the number of system calls mkpatch & dopatch 
require and thus would probably prove more efficient. But I admit that 
this is a small detail at this point of the discussion.

> Those files would stand for all patch logs between N and M.  If their
> content is uniquely defined by the content of all the patch-N to patch-M
> files, then it's pretty easy to avoid conflicts.
>  

What would you put in those files? The goal of the summary files was 
also to remove all but one log messages we currently have in our working 
trees and, using the same notation, to reduce log-for-merge output. The 
current state of things makes the {arch} directory sometimes count for 
an important part of the size of the whole tree. For instance in 
arch-1.2pre2/src/tla:

        tla$ du -sk .
        17986   .
        $ du -sk \{arch\}/
        12284   {arch}


Robin