[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork a
From: |
Timothy Brownawell |
Subject: |
[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove |
Date: |
Sun, 09 May 2010 00:31:37 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100501 Iceweasel/3.5.9 (like Firefox/3.5.9) |
Follow-up Comment #5, bug #17878 (project monotone):
Oh, hm, it doesn't.
I don't particularly like the idea of making 'commit' become unpredictably
interactive. It means there's an extra step between "commit, go back to
coding" which is "wait to see if 'commit' asked anything", and it breaks "run
'make check && mtn ci -m foo && mtn sy', go do something else for a while
while that runs", and it just doesn't seem that good an idea to have it be
"you have to watch this to see if it needs input, but it usually doesn't".
So that leaves the other option, having 'merge', 'disapprove',
'merge_into_dir', 'propagate', and maybe 'explicit_merge', 'pull', 'sync',
'approve', and 'suspend' update the workspace (and take a --no-update flag to
turn this off). But I like having things be orthogonal too (and suspect it
helps with learning the concepts), and this would break that somewhat.
I suppose practicality is probably more important here than prettiness, so
what would be good criteria for updating? Say, the base revision goes from
being a head to not being a head (if it's already not a head, presumably the
user did 'update -r ...' and wants it to stay there) and doesn't contain any
uncommitted changes (making them possibly go through conflict resolution when
they didn't ask for it seems impolite)? This still leaves the potential for
confusion from having multiple workspaces (only one would be updated) and
different behavior of non-workspace commands based on being in a workspace and
on *accidentally* not being at a head revision (say because your last pull was
done outside a workspace). Does the extra convenience outweigh the potential
for extra (different) confusion?
I suppose I'll add '--update' and '--no-update' flags for those commands, and
we can go bikeshed later on which should be the default.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?17878>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Timothy Brownawell, 2010/05/08
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Thomas Keller, 2010/05/08
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Ludovic Brenta, 2010/05/08
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove,
Timothy Brownawell <=
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Ludovic Brenta, 2010/05/09
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Stephen Leake, 2010/05/09
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Thomas Keller, 2010/05/09
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Timothy Brownawell, 2010/05/16
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Ludovic Brenta, 2010/05/16
- [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Timothy Brownawell, 2010/05/16
- Re: [Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove, Derek Scherger, 2010/05/09