[Top][All Lists]

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

Re: [Gnu-arch-users] Fast commits

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Fast commits
Date: Sat, 03 Apr 2004 14:49:04 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

Tom Lord wrote:

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

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

I've been giving some thought to merge lately. Thinking about how to satisfy Linus, who wants a graphical three-way merge. So far, I've come up with this:

- star-merge is not a fundamental operation, in the sense that get, update and commit are. It's not an archive operation, in the sense that it does not produce or store revisions.

- Since it's not an archive operation, the implementation doesn't matter to anyone but the user. A good merge operation will produce fewer conflicts. A bad merge operation will produce more. But no one else will be affected.

- To satisfy Linus, itla would need to break star-merge into several steps:

1. find/make the two other trees (the common ancestor revision and the requested revision)

2. apply the differences between the common ancestor and the requested revision to the project tree. This step may use any available tool, from diff3 to tkdiff to some proprietary thing.

3. cleanup: delete the two other trees.

So in a fundamental sense, I don't think there's anything wrong with varying the way merges work (say, by special-casing patchlogs), though this may not be the time or place for such changes.


reply via email to

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