RFC: dealing with dead, anonymous feature branches

[Gilles Moris]

On Friday 07 May 2010 07:34:23 pm Martin Geisler wrote:
> One of the very first times I talked about Mercurial here in Zurich, I
> was asked what one should do if a set of changesets turned out to be
> useless -- an abandoned feature branch. When I say "branch" in the
> following, I'm not talking about named branches, I'm just talking about
> topological branches, named or not.
>
> I suggested a dummy merge, but that is a bad answer since Mercurial will
> believe you when you say you've merged the branch and if you later
> change your mind you wont get what you want.
>
> One better answer could be: just delete your clone. However, this only
> really works if the changesets have not been shared very far since
> everybody has to remember to delete his clone.
>
> The people I've talked to is also not very happy about setting up many
> clones. Each working copy needs to be setup so they prefer a single.
>
>
> My idea is a simple: we already have the --close-branch flag for commit
> which inserts close=1 in the extra dictionary. Call such a head
> "closed", other heads are "open". I propose that we do not push or pull
> closed heads.

I am not sure this is the direction I would like to see happen. I understand 
that "closed history" can cause some cluttering, but I think not sending some 
changesets on push/pull is a disruptive behavior. Do we already do that in 
some situation, except explicitly requested through a "-r" option. And after 
all, closed history is history, so why not push it anyway ?

I am more concerned the close-branch behavior itself. May be I am stupid, but 
I have hard time to understand the logic behind the current implementation. 
Actually, I would really like to use that feature, but never did it because I 
am confused how all the commands reacts. And I must not be alone as I 
remember several questions on that topic in the mailing list.

Setting aside compatibility issues with the CLI, repo format, perf issues, my 
ideal requirements would be:
1/ It shall be possible to close a head, no distinction between branch head or 
topological heads (too confusing for newbie IMO)
2/ Trying to close a changeset that is not a head (either branch head or 
topological) shall raise an error. Why would we allow that ?
3/ the "heads" command shall not show a changeset that is closed, whether it's 
a branch or a topo head, except if the --closed option is set.
4/ The "branches" commands shall not show a branch if all its branch heads are 
closed, except if the --closed option is set.
5/ Closed heads shall not be considered for default/implicit head selection of 
the update or merge commands
6/ The user shall be warned when committing from a closed parent head. Either:
6a/ This should raise a error, except if a --force option to commit is set. 
May be too extreme solution I guess.
6b/ When committing over a closed head parent, the commit command shall 
display a message: "Resurrecting closed head"
7/ Closed changesets shall be marked more explicitly in showed changesets, 
i.e. for commands like log, incoming, ..., and may be also in identify and 
summary.

With that, I would be satisfied if push/pull stays the same. Are those 
requirements are:
- already the case
- reasonable
- achievable

Regards.
Gilles.