What we did at UBZ

[Jan Hudec]

On Sun, Nov 20, 2005 at 08:49:40 -0600, John A Meinel wrote:
> 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.

Depends on what it does. What I want is pull to (always) work the source has
fully merged destination, no matter as what parent. Because IMHO pull should
be defined that way. Because IMHO branch is FULLY defined by it's head
revision. But I think it's easier on newcommers if it requires an option if
the destination current head is non-first parent of the source revision. It's
OK with 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.
> 
> 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).

I don't like that. It's a special-case. And I also consider the changelog
a change.

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

... but telling whether two branches are actually equal would rely on some
hairy logic in bzr. I'd like to simply have "two branches are equal iff
$(bzr revno --id this) == $(bzr revno --id that)

Note: I failed to find a command to show revision id, which I think should be
possible.

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

If destination head is not ancestor of the source, it does not belong to pull
at all IMHO. It belongs to branch. Because it does not pull new changes, it
replaces current directory with a different branch.

By the way, I don't want anything *less* clobbering -- I want something *not*
clobbering. It does not clobber anything. It just changes the order in which
revisions are printed in the changelog.

-- 
						 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/3b5c0e08/attachment.pgp