[PATCH 0 of 3] An attept at branch closing

[John Mulligan]

On Sunday 05 October 2008 3:10:16 pm Matt Mackall wrote:
> On Sat, 2008-10-04 at 16:28 -0400, John Mulligan wrote:
> > I have a Mercurial repository that was converted from CVS and has a lot
> > of branches I don't want to see, but some that I do. This motivated my to
> > try and implement a mechanism for (the oft requested?) named branch
> > closing. I haven't heard about much activity on the subject lately, so I
> > hope I'm not stepping on anyones toes who may have also been working on
> > this.
> >
> > I took my lead from this post of Matt's:
> >   http://selenic.com/pipermail/mercurial-devel/2008-March/005144.html
> >
> > I added a --close-branch option to commit. This adds a extra 'close'
> > attribute to the changeset makes the branch dissapear from heads
> > and branches. To revive a branch you must hg up to the rev number
> > and make a commit.
> >
> > I have also added tests for the branch closing.
> >
> > Please feel free beat up on this. :-)
> >
> >
> > Open Issues
> > ===========
> >
> >  * After `hg commit --close-branch -m "close messy branch"` what
> >    branch should the working dir be on? Currently the parent will be
> >    the cset with the close marker, and making a change and committing
> >    will re-open the branch!
>
> An excellent point. But at the same time, it's completely 'natural' once
> you understand the Mercurial basics.
>

Agreed. It's probably not an everyday action which is also good, but still a 
potential gotcha for new users.

> >  * Should the log print something like:
> >
> >       changeset:   8:7db20c52f570
> >       branch:      b (closed)
> >       parent:      4:aee39cd168d0
> >       user:        test
> >       date:        Thu Jan 01 00:00:07 1970 +0000
> >       summary:     zap b branch
>
> That might confuse existing parsers.

That makes sense, and the commit message should be written to make what is 
happening clear anyway.

>
> >  * What should happen if the user tries to start a new branch with the
> >    same name as a closed one? Right now, nothing fails, you just end up
> >    with two heads that both consider themselves on the same branch.
>
> I took a stab at writing this code earlier and the fun I ran into was
> primarily in handling the branch cache. Imagine this tree:
>
> A1-A2-A3-A4-B1-B2-B3
>      \
>       A5-A6-A9 (tip)
>         \
>          A7-A8
>
> If we close A9 by adding a close at A10, the A branch is still open
> because it has an open head at A8. The head at A4 is inactive by virtue
> of having a child on a different branch.
>
> And that means as we're building the cache, we have to remember A8 even
> when it gets overridden by A9, because A10 might come along and make A8
> the branch tip again.

Ah. I don't know if you could tell from my patches but I tried to work 
above/around the cache, since I couldn't fully wrap my puny brain around it. 
:-)

If I follow you correctly, we would have to require the branch to only have 
one (active?) head at the time of closing. But I still don't fully get all the 
implications of the cache, so I will probably have to go back and read the 
existing code a few more times, and maybe I'll achieve enlightenment.

Thanks for the feedback...

--John M