star or parallele merge

[John A Meinel]

William Dode wrote:
> On 29-09-2005, Aaron Bentley wrote:
> 
>>William Dode wrote:
>>
>>>I've one project used by two clients. To now i use star merging, with 3
>>>branchs, one main, and one for each clients. When i make a feature for
>>>one i do it on his branch, when it's finish i merge it to the main
>>>branch and from the main to the other one.
>>>
>>>I wonder, now that i use bzr (i was using tla and bazaar), if it will
>>>be possible and better to don't use the main branch, and just keep one
>>>branch for each and merge between them directly. Specialy that i don't 
>>>need the main branch for anything else (i'm alone for this private
>>>project).
>>
>>Using just two branches sounds fine, in theory.  I don't really
>>understand why you're using three brances with tla, so I can't be sure
>>that bzr handles the issue better.
> 
> 
> No special reason, i just used to do like that...
> 
> I don't know if it's because of parrallele merging but even if it works
> sometimes i do `bzr pull` it answer that "0 conflicts encountered." fine, but
> if i do after `bzr missing` it answer that i miss something... Shall i
> show somes example or is it normal (old format) ?

"bzr missing" is older code that hasn't been updated for some newer 
concepts.

Basically, "bzr missing" just checks to see if the revision-history of 
both branches is identical. However, with merges, it is now possible to 
have 2 trees converge. (If I merge you, you can pull that revision, and 
then our trees are effectively identical, though the explicit path 
through history is different).
I can give more detailed examples of what I mean if it isn't clear.

I'm not sure what "bzr missing" should display anymore. Perhaps it 
should ask to find the common ancestor of the two trees, and then try 
and display only the entries in revision-history from that common ancestor.

Or perhaps with the new format, and ancestry.weave, it can just do the 
set difference, and display those (though we need to keep them in order).

This has a small difference, that it will show missing merged revisions 
too. For example:

#1 A - B - C - D - E - F
#    \       \
#2     G - H - I

At this point, tree 2 should show D-E-F as missing from 1, and tree 1 
should show G-H-I as missing from 2.

#1 A - B - C - D - E - F
#  | \       \
#2  \  G - H - I - M
#    \           /
#3     J - K - L

The question here, is that "cd $1; bzr missing $2"
should certainly show G-H-I-M, but should it show J-K-L as well?

The current missing code would not, since it looks only at 
revision-history, but since that doesn't work quite right after merges, 
what do we want it to do? I'm worried that showing J-K-L could be 
considered clutter (they weren't "produced" on this branch, and showing 
M might be all you really want to see).

Anybody have ideas?

John
=:->

> 
> 
>>>Is there a sort of documentation about differents organisations of 
>>>branchs on the wiki ?
>>
>>I don't think there is, yet.
> 
> 
> It could be very interresting to rewrite the famous tla tutorial with
> bzr commands. I think i'll do it in french (i've translated the tla
> tutorial in french).
> 

-------------- 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/20051002/f8e29c09/attachment.pgp