monotone-devel
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]