What we did at UBZ

[John A Meinel]

Jan Hudec wrote:
> On Fri, Nov 18, 2005 at 17:40:22 -0500, Aaron Bentley wrote:
>> Jan Hudec wrote:
> [...]
>>>  - And of course, the definition of pull remains that it can only apply
>>>    revisions, that are descenants of the current destination head.
>> No, the definition becomes that pull can only apply revisions that are
>> desdants of the current destination head, and that the destination head
>> must be the first parent.
> 
> It will _not_ be the first parent. It will be second one if it's a merge.

The point is that we will restrict branches from converging. Once you
have committed something different from me, from there on, and ever
after, you must merge from me, you are no longer able to pull.

I kind of like it, and kind of don't.

It gives branches more of an identity, because two *branches* no longer
share the same revisions in their mainline. They may share
ancestors/merged revisions, and the mainline before the branching, but
not after.

It means that I can't do some work, have you merge it, and then pull
up-to-date, and then do more work in the same branch. I would have to
merge up-to-date.
What I don't like about that, is all of the extra commits that have to
happen, if I temporarily do some hacking, and then want to stay on the
official release for a while, and then do more hacking later.
However, we do still offer "pull --overwrite", which means that I can
"switch" my branch back to the official release.
Then my branch no longer exists as an obvious entity, though because of
the rules, you could go back through the revisions to find any that
don't have children with them as first parent, and you know that is the
tip of some branch.

I guess for me it isn't a really big deal. I tend to develop on either
feature branches, which tend to be short-lived, or on an integration
branch, which generally needs to use merge to stay up to date anyway.

John
=:->


> 
> I believe it should work when the destination current head is not the first
> parent. However as it always considers the first parent a mainline, it will
> then show different mainline. I believe that's correct -- the branch is no
> longer the same, but rather the old one was merged and forgotten and a new
> one is created in the same directory.
> 
>>> Follows from that that after pull, the destination branch shows history
>>> exactly the same as the source did. Actually it should be exactly equivalent
>>> to source.
>> Which is a change.
> 
> Ok.
> 


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