Re: Warning to Debian Developers regarding BitKeeper
Brian May <bam@debian.org> wrote:
> On Wed, Oct 09, 2002 at 01:25:40AM -0700, Walter Landry wrote:
> > This is a bit complicated, so I'll give you the short form. When arch
> > merges two trees that were once related to each other, it only applies
> > patches made since the last two trees were synced. So if you made
> > local modifications, you only have to tell arch once not to overwrite
> > them. Or you may not have to tell arch that at all.
> >
> > Actually doing the merge is still grunt work. As I said, it doesn't
> > have the slick gui that BitKeeper has. I'm working on that, but don't
> > expect any miracles.
>
> So what happens when I conflict is identified? So far I have seen 3
> mechanisms:
>
> 1. mark the section in the file with both versions (CVS).
>
> 2. create a new *.rej file containing all changes that could not
> be applied (patch).
This is what it does now. That makes it easy to find out which files
didn't merge properly (just "ls -R | grep rej").
> 3. 3 way GUI merge (bitkeeper).
This is what I'm working on.
> My preference, believe it or not, is currently 1. I find 2 annoying,
> because I have to keep track of the rej file at the same time as editing
> the patched file, and 3 annoying at times when I am not running X...
>
> Also, I have often been puzzling over one difference between bitkeeper,
> and arch. bitkeeper has two merge operations "push", and "pull".
>
> arch on the other hand has numerous merge operations: "update",
> "replay", "star-merge", "reconcile" (any others?).
"whats-missing", which tells you which patches are missing from your
tree.
> Is there any good reason arch needs so many, when bitkeeper can get away
> with having so few?
"update" and "replay" only deal with two different trees. "star-merge"
deals with three. "reconcile" just tells you which sets of patches
you need to apply. "reconcile" is only needed for horrific merges
(e.g. 10 different trees, which all have varying numbers of patches
from each other, in various orders).
> Current version of arch documentation don't make it clear
> for instance, why I would want to choose "update" other "replay"
> or vice versa, so all of these operations leave me a bit confused.
"update" applies the patches missing from one tree to another as one
big patch. "replay" applies each patch in order. You may find it
simpler to do them one at a time, especially if there are a lot of
complicated conflicts. It also makes it clear which patch caused the
conflict.
Most of the time, "update" is what you want.
But I appreciate your point, which is that the doc's both suck and blow.
Regards,
Walter Landry
wlandry@ucsd.edu
Reply to: