atom feed69 messages in com.selenic.mercurial-develRe: RFC: dealing with dead, anonymous...
FromSent OnAttachments
Martin GeislerMay 7, 2010 10:33 am 
Dirkjan OchtmanMay 7, 2010 10:37 am 
Matt MackallMay 7, 2010 10:59 am 
Martin GeislerMay 7, 2010 11:14 am 
Matt MackallMay 7, 2010 11:46 am 
Dirkjan OchtmanMay 7, 2010 1:14 pm 
Gilles MorisMay 8, 2010 12:10 am 
Martin GeislerMay 8, 2010 1:31 am 
Martin GeislerMay 8, 2010 1:34 am 
Martin GeislerMay 8, 2010 1:48 am 
Martin GeislerMay 8, 2010 2:09 am 
Gilles MorisMay 8, 2010 3:50 am 
Martin GeislerMay 8, 2010 1:10 pm 
Gilles MorisMay 9, 2010 9:33 am 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Matt MackallMay 9, 2010 2:36 pm 
Matt MackallMay 9, 2010 2:43 pm 
Matt MackallMay 9, 2010 2:45 pm 
Matt MackallMay 9, 2010 2:47 pm 
Martin GeislerMay 9, 2010 4:11 pm 
Dirkjan OchtmanMay 9, 2010 10:50 pm 
Gilles MorisMay 9, 2010 11:31 pm 
Gilles MorisMay 9, 2010 11:49 pm 
Matt MackallMay 10, 2010 12:04 am 
Gilles MorisMay 10, 2010 12:37 am 
Gilles MorisMay 10, 2010 12:37 am 
Matt MackallMay 10, 2010 12:38 am 
Matt MackallMay 10, 2010 12:58 am 
Sune FoldagerMay 11, 2010 2:02 am 
Sune FoldagerMay 11, 2010 2:08 am 
Sune FoldagerMay 11, 2010 2:14 am 
Sune FoldagerMay 11, 2010 2:20 am 
Matt MackallMay 11, 2010 3:53 pm 
Matt MackallMay 11, 2010 3:56 pm 
Gilles MorisMay 12, 2010 12:52 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 5:17 am 
Augie FacklerMay 12, 2010 7:35 am 
Matt MackallMay 12, 2010 8:33 am 
Matt MackallMay 12, 2010 8:34 am 
Matt MackallMay 12, 2010 8:34 am 
Matt MackallMay 12, 2010 8:55 am 
Gilles MorisMay 12, 2010 2:33 pm 
Gilles MorisMay 13, 2010 7:31 am 
Matt MackallMay 13, 2010 1:48 pm 
Martin GeislerMay 17, 2010 1:09 am 
Martin GeislerMay 17, 2010 1:22 am 
Rafael Villar Burke (Pachi)May 17, 2010 2:07 am 
Augie FacklerMay 17, 2010 5:57 am 
Martin GeislerMay 17, 2010 6:56 am 
Augie FacklerMay 17, 2010 7:46 am 
Martin GeislerMay 17, 2010 8:13 am 
Augie FacklerMay 17, 2010 8:41 am 
Gilles MorisMay 19, 2010 8:00 am 
Martin GeislerMay 19, 2010 3:53 pm 
Martin GeislerMay 19, 2010 3:58 pm 
Augie FacklerMay 24, 2010 5:15 am 
Peter ArrenbrechtMay 26, 2010 6:23 am 
Rafael Fernández LópezJun 3, 2010 5:35 am 
Peter ArrenbrechtJun 3, 2010 6:14 am 
Martin GeislerJun 4, 2010 12:18 am 
Subject:Re: RFC: dealing with dead, anonymous feature branches
From:Gilles Moris (gill@free.fr)
Date:May 8, 2010 12:10:00 am
List:com.selenic.mercurial-devel

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.