Re: New branch

[Stephen J. Turnbull]

Stefan Monnier writes:

 > But note that in the context of Bzr, those questions don't have the same
 > importance&meaning as within CVS.

That's right; they're *far* more important! ;-)

 > After all, creating a branch is
 > nothing else than cloning, so initially the new branch is absolutely
 > identical to the "parent".
 > I expect at some point we'll do something like:
 > 
 >   (cd pending; bzr merge ../trunk; bzr commit)
 >   mv trunk emacs-23.2
 >   mv pending trunk

Gawd, no!  For that to work, you really want to be rebasing pending on
to trunk after *every* commit to trunk.  Otherwise, what you propose
here will AFAICT result in exactly the kind of Mainline Twist that you
personally just set ARO to prevent.  But that seems like makework to
me.  The whole point of having a pending branch should be that they
can go their separate ways for a while, and during that while, commits
of new code to the public branches are discouraged and require effort
to (a) do and (b) test.

If you are not trying to discourage work on new code, then you should
cut a separate release branch.

 > or maybe
 > 
 >   bzr clone trunk emacs-23.2
 >   (cd trunk; bzr merge ../pending; bzr commit)
 >   rm -rf pending

Better, but that last line should give you pause.  Sure, it's needed,
because pending is now obsolete.  But bzr gives no way to notify
people of that except that their attempts to pull or push will fail (I
hope).

It seems to me that pending is not a great idea.  Patches that don't
belong in trunk can just stay in personal private or public branches
until trunk opens again.  If pending would really accumulate
significant amounts of work, your release process has more problems
than just "where to put pending work".