gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Fast commits


From: Tom Lord
Subject: Re: [Gnu-arch-users] Fast commits
Date: Sat, 3 Apr 2004 11:31:01 -0800 (PST)


    Robin:
    >> Let us suppose we replace the patch-log directory with
    >> three files. [....]

    Tom:
    > It's a very promising idea in general terms (ignoring inessential
    > details of what you are describing).  It would need more thought about
    > what exactly goes into the summary files you are describing, how they
    > will be managed to avoid lossage, how they interact with changeset
    > computation and application, and how that will impact various forms of
    > query.  Plus the things on top of those that I'm forgetting right now.

I should add to that, this:

One nice thing about the way patch-logs currently work is that mkpatch
and dopatch don't have to know anything (much) special about them.
Merging creates (perhaps redundently) new files;   reverting removes
(perhaps redundently) old files.

It's not impossible to get conflicts in the patch log but it's pretty
hard and the easiest way I know of to do it is a bug and will go away.

So, summary files instead of patch-log is an interesting idea -- but 
one question is whether it hairs-up mkpatch/dopatch or whether the
format can be designed in such a way that the nice properties of the
current system can be preserved.

(Now that you mention it -- I think a similar idea _did_ come up a
long time ago but the mkpatch/dopatch hair was the stumbling block.
One thing that has changed since then is that I might now be more
willing to consider a little mkpatch/dopatch hair than I was then.)

-t





reply via email to

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