What we did at UBZ

[John A Meinel]

Jan Hudec wrote:
> On Sun, Nov 20, 2005 at 08:09:25 -0600, John A Meinel wrote:
>> 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.
> 
> But when you merge me back, your branch becomes superset of my. So I want
> pull to work again and turn my branch into copy of yours (exact copy --
> I don't need it to remember which commits were from me).

That is what "pull --overwrite" is for. You can transform your branch
into any descendant, but then it becomes that descendant, not some other
branch which happens to share some of the history, but not all of it.

> 
>> 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.
> 
> ... but I would not be up-to-date after that, because merge, unlike pull,
> creates new changeset. But that changeset is exactly my head -- so I don't
> want it to be created.

Well, there is a simple way to have "bzr merge ../a" notice that there
were no changes other than a new revision, and thus it has nothing new
to commit. (In implementation terms, it doesn't add a value to
pending-merges if there are no actual changes).

You effectively have convergence, because a new merge does nothing.

> 
>> 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.
> 
> I have discussed a use-case some time ago on the svk mailing list, where it
> really hurted that it can't converge.
> 
> Also I think there is gain in restricting pull when the destination current
> head is not the first parent. It might be a bit confusing for someone, but if
> it's documented properly...
> 

Is there a reason --overwrite is not sufficient? Perhaps you want
something a little bit less clobbering, like --overwrite-if-ancestor, so
that it will only overwrite if your current revision is an ancestor.
This would prevent you from switching when the other branch hasn't
merged all of you yet, but would still let you change your branch into
theirs if they have.

John
=:->

-------------- 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/46709d86/attachment.pgp