Discussion about merging

[John A Meinel]

I think I forgot to send this earlier. Forgive me if this is a re-send.
John
=:->


David Allouche wrote:

>On Tue, 2005-06-07 at 10:45 -0500, John A Meinel wrote:
>
>
>>David Allouche wrote:
>>
>>
>>>With bzr, as long as there is no divergence, you need not do merges,
>>>just pulls. And if there is ever a divergence you only need one merge
>>>(summary changeset) to fix it and go back to the desired situation: two
>>>branches with the same ancestry.
>>>
>>>
>>I don't know if merge will properly merge ancestry for you. As I think
>>the interior revision-id will be different. However, because of the
>>unique identifiers, you can actually undo one of the commits, merge the
>>other commit, and then replay the original commit. Then just replay that
>>last commit on the other branch, and they are back to having identical
>>history.
>>
>>
>
>My lack of practical experience with bzr is starting to show :) I'll try
>to clarify what I meant:
>
>The use case is: one person works on the same branch from two different
>but connected systems, Laptop and and Desktop.
>
>There are essentially two scenario. The common-case scenario is the
>absence of divergence:
>
>     1. Initially, the trees are identical on Desktop and Laptop.
>     2. User makes commits on on laptop.
>     3. User transmits new commits to Desktop, and update the Desktop
>        tree.
>     4. Both branches now have the same ancestry.
>
>In that scenario, no merge is involved, so the granularity of all
>commits, regardless the originating system, is preserved in the ancestry
>at no effort.
>
>
Perfectly true. Under the circumstance that you have to .bzr
directories, but you commit to only one at a time, and you synchronize
before committing to the other one, all you have to do is "pull".

>The exceptional scenario, the one that make it necessary to use
>different branches in the Arch model is the occurrence of divergence.
>
>     1. Initially, the trees are identical on Desktop and Laptop.
>     2. User makes commits on Laptop.
>     3. User is sloppy, or has to make an emergency fix, and commits on
>        Desktop.
>     4. At this point, Desktop and Laptop have different ideas of what
>        is the latest commit on the branch. In Arch, that's very, very
>        bad. But in Bazaar-NG, that's not a problem.
>     5. User transmits Laptop's commits to Desktop, and performs a
>        merge.
>     6. User syncs (e.g. with rsync) Laptop from Desktop, effectively
>        changing the history of the branch stored on the Laptop. Then
>        the latest revision on both systems in the merge done at 5.
>
>My point is that Arch requires you to use different (namespace) branches
>and merge every time, because it cannot cope with the exceptional
>divergence. Bazaar-NG has no such issue, so the common case scenario
>stays simple, and merges are only required when a divergence occurred.
>
>
Exactly true, arch doesn't handle this very well at all.
There are 2 points here. bzr does have the concept of the
"revision_history" where each revision has a specific precursor, and
refers to an specific working tree snapshot. There are 2 types of
"merging", there is updating, where each revision keeps the same id, the
same tree snapshot, and the same precursor, and there is merging, where
I have to take your changes, and apply them to a different "precursor",
thus generating a new revision id.

For 2 .bzr directories to truly be the same "branch" they have to have
the same revision history. The problem with the dual commit, is that you
now have 2 revision ids with the same precursor, obviously one has to
change for you to have a linear history, which is identical in both
directories.

To do it well in bzr, would mean un-committing the divergent commits,
replaying one trees history, and generating a new commit. This commit
can then be "pulled" onto the other branch, and the revision history for
both trees will be identical.

The other way to make the trees effectively the same (but not identical)
is to do a "merge" of the changes. That also generates a new
revision_id, with it's associated stuff, but it should also put into the
list of merges those patches that were just added.
(Note: bzr does not have this functionality yet. The current merge
command only affects the files in the working directory. It does not add
anything to the revision history or merged patches files).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050616/2a453b29/attachment.pgp