[PATCH 0 of 9] improvements for named branches

[Matt Mackall]

On Tue, Mar 04, 2008 at 03:08:19AM -0300, Alexis S. L. Carvalho wrote:
> First I have to ask (and give my version of the answers):
> 
> What are some use cases that you see for named branches?
> 
>   - long-lived branches like stable
> 
>   - some feature that would take a longer time to develop, and so is
>     kept somewhat separate from the main development
> 
>   - in general, if somebody doesn't want to make a full clone, I'd like
>     to have a way to have multiple lines of development in the same
>     repo, without having to manually keep track of hexnodes.  Maybe
>     named branches will still be too heavy for this even after more
>     changes, but I'd like to try to make them more useful for this case
> 
> When would one want to close/inactivate/... a named branch?
> 
>   For long-lived branches, never.
> 
>   For the other cases, when the work is ready to be merged into the main
>   line of development.  In particular, closing of branches would happen
>   mostly in merge revisions.
> 
>   If that line of development was considered a failure...  Well, without
>   named branches the usual recommendation is to "discard" that head
>   using merge+revert, which could also be an option here.  And then the
>   branch could be closed during the merge commit.

The usual recommendation is to never push that branch. So instead,
we've got 4 cases:

1 long-lived branch (stable)
2 short-lived branch merged back and pushed (feature)
3 short-lived local branch discarded (misfeature)
4 short-lived unmerged branch on public server we want to hide (embarrassment)

If my default path has a #default or #stable in it, I automatically
won't ever show my misfeature branch until I merge. If not, and I
decide to publish my misfeature branch, thus making it an
embarrassment, I probably -don't- want to merge it as it will pollute
history for people who *are* doing a pull #default, I'll never be able
to strip it, and I'll never be able to live it down.

> What does it mean to close/inactivate/... a named branch?
> 
>   To make it look as if that name never existed (but you could still
>   recalculate them if you're doing archaeology).

Ok, so when a bonehead does merge --close stable, I now have to do
archaeology? (Haha.. bonehead.. archaeology..) That sounds *bad*. The
bonehead will have no idea he typed --close (his fingers are faster
than his little dinosaur brain), and everyone will say "where the hell
did our stable branch go! our build server just wet itself! this
software is crap!" and no one will know who to blame and they'll all
wave their tiny little T-rex arms about in panic.

Instead, I'd like this "branch closing" to be about giving a more
useful meaning to "active branches" (hg branch -a), such that we can
stop checking out  (and listing) "inactive (closed)" branches by
default, but they still live on for the purposes of hg up, log, etc.

Compare deleting a tag: I've got to actually consciously do a whole
"hg tag --delete 1.0" and then even a slightly clueful person can do
hg log .hgtags to find the appropriate cruise missile coordinates.

With "hg commit --close branch" simply marking the branch inactive,
people instead say "huh, stable still works great, but stopped showing
up as an active branch. how odd. hg log -b stable shows that
'maverick' closed it, and his commit message shows why he thinks we
don't need a stable branch any more. let's go have a little chat with
him after lunch about who's in charge."

> > Also, what happens if you do:
> > 
> > hg branch --close thisbranch
> 
> abort: refusing to close current branch "thisbranch"

This is the embarrassment case:

hg co embarrassment
hg commit --close-branch -m "Sorry you had to see that, folks"
hg push -r embarrassment

Our embarrassment now moves to the bottom or even disappears from hg
branches, and we might not show it on hg heads either unless we pass a
--inactive.

> > Also, how do you unclose a branch before commit?
> 
> Right now with a very well hidden hg branch --close ''
> 
> > I'd rather require an explicit commit on the branch head(s) to move it
> > to the "inactive" state. Then a "closed" branch is one where all its
> > heads are inactive.
> 
> You mean something like extra['branch'] = 'foo'; extra['closed'] = 1
> would mean that this commit should not be considered an open head of the
> named branch "foo"?

Right.

> What I think is important is to have pull/push/clone -r transfer all the
> heads of the repo and have log -r show all the heads.  In general, make
> all commands that can operate on multiple revisions operate on all the
> heads.

??

-- 
Mathematics is the supreme nostalgia of our time.