| From | Sent On | Attachments |
|---|---|---|
| Martin Geisler | May 7, 2010 10:33 am | |
| Dirkjan Ochtman | May 7, 2010 10:37 am | |
| Matt Mackall | May 7, 2010 10:59 am | |
| Martin Geisler | May 7, 2010 11:14 am | |
| Matt Mackall | May 7, 2010 11:46 am | |
| Dirkjan Ochtman | May 7, 2010 1:14 pm | |
| Gilles Moris | May 8, 2010 12:10 am | |
| Martin Geisler | May 8, 2010 1:31 am | |
| Martin Geisler | May 8, 2010 1:34 am | |
| Martin Geisler | May 8, 2010 1:48 am | |
| Martin Geisler | May 8, 2010 2:09 am | |
| Gilles Moris | May 8, 2010 3:50 am | |
| Martin Geisler | May 8, 2010 1:10 pm | |
| Gilles Moris | May 9, 2010 9:33 am | |
| Gilles Moris | May 9, 2010 1:49 pm | |
| Gilles Moris | May 9, 2010 1:49 pm | |
| Gilles Moris | May 9, 2010 1:49 pm | |
| Gilles Moris | May 9, 2010 1:49 pm | |
| Gilles Moris | May 9, 2010 1:49 pm | |
| Matt Mackall | May 9, 2010 2:36 pm | |
| Matt Mackall | May 9, 2010 2:43 pm | |
| Matt Mackall | May 9, 2010 2:45 pm | |
| Matt Mackall | May 9, 2010 2:47 pm | |
| Martin Geisler | May 9, 2010 4:11 pm | |
| Dirkjan Ochtman | May 9, 2010 10:50 pm | |
| Gilles Moris | May 9, 2010 11:31 pm | |
| Gilles Moris | May 9, 2010 11:49 pm | |
| Matt Mackall | May 10, 2010 12:04 am | |
| Gilles Moris | May 10, 2010 12:37 am | |
| Gilles Moris | May 10, 2010 12:37 am | |
| Matt Mackall | May 10, 2010 12:38 am | |
| Matt Mackall | May 10, 2010 12:58 am | |
| Sune Foldager | May 11, 2010 2:02 am | |
| Sune Foldager | May 11, 2010 2:08 am | |
| Sune Foldager | May 11, 2010 2:14 am | |
| Sune Foldager | May 11, 2010 2:20 am | |
| Matt Mackall | May 11, 2010 3:53 pm | |
| Matt Mackall | May 11, 2010 3:56 pm | |
| Gilles Moris | May 12, 2010 12:52 am | |
| Gilles Moris | May 12, 2010 1:15 am | |
| Gilles Moris | May 12, 2010 1:15 am | |
| Gilles Moris | May 12, 2010 1:15 am | |
| Gilles Moris | May 12, 2010 1:15 am | |
| Gilles Moris | May 12, 2010 1:15 am | |
| Gilles Moris | May 12, 2010 5:17 am | |
| Augie Fackler | May 12, 2010 7:35 am | |
| Matt Mackall | May 12, 2010 8:33 am | |
| Matt Mackall | May 12, 2010 8:34 am | |
| Matt Mackall | May 12, 2010 8:34 am | |
| Matt Mackall | May 12, 2010 8:55 am | |
| Gilles Moris | May 12, 2010 2:33 pm | |
| Gilles Moris | May 13, 2010 7:31 am | |
| Matt Mackall | May 13, 2010 1:48 pm | |
| Martin Geisler | May 17, 2010 1:09 am | |
| Martin Geisler | May 17, 2010 1:22 am | |
| Rafael Villar Burke (Pachi) | May 17, 2010 2:07 am | |
| Augie Fackler | May 17, 2010 5:57 am | |
| Martin Geisler | May 17, 2010 6:56 am | |
| Augie Fackler | May 17, 2010 7:46 am | |
| Martin Geisler | May 17, 2010 8:13 am | |
| Augie Fackler | May 17, 2010 8:41 am | |
| Gilles Moris | May 19, 2010 8:00 am | |
| Martin Geisler | May 19, 2010 3:53 pm | |
| Martin Geisler | May 19, 2010 3:58 pm | |
| Augie Fackler | May 24, 2010 5:15 am | |
| Peter Arrenbrecht | May 26, 2010 6:23 am | |
| Rafael Fernández López | Jun 3, 2010 5:35 am | |
| Peter Arrenbrecht | Jun 3, 2010 6:14 am | |
| Martin Geisler | Jun 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.
_______________________________________________ Mercurial-devel mailing list Merc...@selenic.com http://selenic.com/mailman/listinfo/mercurial-devel





