Re: Warning to Debian Developers regarding BitKeeper
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).
3. 3 way GUI merge (bitkeeper).
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?).
Is there any good reason arch needs so many, when bitkeeper can get away
with having so few?
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.
--
Brian May <bam@debian.org>
Reply to: