bazaar-ng talk on darcs mailinglist.

[Martin Pool]

Erik Bågfors wrote:
> Just wanted to let you know about some talk about bazaar-ng on the
> darcs-users mailinglist
>
> You can follow it from here
> http://www.abridgegame.org/pipermail/darcs-users/2005-March/006320.html
> which is when I intruduced bazaar-ng to the list :)

Yes, I saw.  Thanks.

> http://www.abridgegame.org/pipermail/darcs-users/2005-March/006380.html
> is interesting, and I have to agree with the guy that wrote that mail
> that it's somewhat simpler in darcs.

That part of the design is not settled yet and if it can be any simpler
I'd like to make it so.  I do enormously admire the simplicity of darcs
and the elegance of the model underneath.

Personally in using darcs I did not find the merge process totally
transparent and friendly; I didn't feel like I really understood what
was happening.  For example, I just did a test of a merge that I would
have thought should give a conflict marker of some kind but it didn't.
  I also can't unpull.  (I am sure I could study and it would probably
make sense but I am trying to think here like a median scm user.)

The basic question is: should you need to commit after a merge to put
the changes into the destination branch?  There are arguments either
way.  Perhaps the strongest argument in favour is that the user should
always have a chance to review or test changes before they're committed;
on the other hand it is simpler to work with only a single command.  A
compromise position is to handle 'trivial' merges differently, where
trivial means either we can prove they're trivial because of the history
graph, or because there are no conflicts and the build/test passes.

The main feature I'd like to take from Arch in handling merges is the
ability to make roll-up commits, representing the merger of several
changes onto a branch.  On the other hand Arch doesn't let you merge
changes without creating new commits, which seems unfortunate.

As of 22:24 tonight, I am leaning towards something a bit more like the
monotone model, and somewhat like the darcs model, where the revision
comes in and unless it's a trivial merge there is a separate commit to
put it on the destination branch.

Comments welcome!

--
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050323/e37ac968/attachment.pgp