[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robin Farine
Subject: Re: [Gnu-arch-users] Re: Fast commits
Date: Sun, 04 Apr 2004 14:21:38 +0200
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

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


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


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):


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


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}


reply via email to

[Prev in Thread] Current Thread [Next in Thread]