[MERGE] Branch format 6

[Erik Bågfors]

On 2/12/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Erik Bågfors wrote:
> > On 2/12/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> >
> >> Erik Bågfors wrote:
> >>
> >> >> I would think the way to do it is
> >> >>   cd mainline
> >> >>   bzr pull
> >> >>   bzr merge ../mystuff
> >> >>   bzr commit -m "Merged my stuff into mainline"
> >> >>   bzr push
> >> >
> >> >
> >> > I don't think this one is so good because it's possible that someone
> >> > committed to mainline in the meantime.
> >>
> >> The same problem exists with bound branches, it's just that the recovery
> >> is different.  If push failed, you'd uncommit, pull, commit and push.
>
> > bzr pull
> > bzr merge ../otherbranch
> > review
> > bzr commit -m merge
> > bzr push -> error message, can't do it
> > bzr uncommit
> > bzr revert
>
> No need.
>
> > bzr pull
> > bzr merge ../otherbranch
>
> No need.
>
> > review
> > bzr commit -m merge
> > bzr push
>
> You've added stuff beyond what I said.  It really is uncommit, pull,
> commit, push.  Perhaps you're not aware that uncommit restores pending
> merges, or that pull works just fine in directories with pending merges?

You're right. I didn't think that far. Once a long time ago, uncommit
didn't restore pending merges :)


> > Compared to
> > bzr update
> > bzr merge ../otherbranch
> > review
> > bzr commit -m merge ---> Error message, run bzr update
> > bzr update
> > review
> > bzr commit -m merge
> >
> > I find the second version nicer :)
>
> I expect this to be a rare circumstance, and I think update is evil
> because it can damage uncommitted changes.  So I would rather stick with
> merge.
>
> You're arguing that using "bind/unbind" is no good for people who don't
> use checkouts, and so we should have "merge --reverse", right?  How
> would merge --reverse be any better?  It would be worse, IMO, because of
> what would happen if you reverted.

Pretty much the same thing as if you reverted after a "bind, update" I
would assume?

Basically, what I'm trying to achive here, is a workflow that's almost
the same where the upstream branch can change it's history, and where
it can't.

So, with append_revisions_only = false, I can do this

bzr branch sftp://foo/foo
cd foo
hack hack commit
hack hack commit
bzr merge; bzr commit
hack hack commit
hack hack commit
bzr merge; bzr commit; bzr push

I can keep one branch and hack on it, I don't need a copy of the
upstream branch.  However, when I push, history changes.

So, with append_revisions_only = true I have to do this

bzr branch sftp://foo/foo
cd foo
hack hack commit
hack hack commit
bzr merge; bzr commit
hack hack commit
hack hack commit
bzr merge; bzr commit; bzr push --> Generates error message I assume
bzr bind sftp://foo/foo
bzr update
bzr commit
bzr unbind

I'm not that fond of that workflow. What I would have to do, is to
have a local copy of the upstream branch to get a good workflow (and
in some/most cases, that might be wanted anyway,  but not always).

I'd like to replace the last bind; update; commit; unbind, with
something like merge --reverse; commit; push. That way a user never
have to know about checkouts/bound branches.

/Erik