What we did at UBZ

[Jan Hudec]

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).

> 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.

> 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...

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051120/91125a6f/attachment.pgp