Christian Ohler <[EMAIL PROTECTED]> writes: > Stephen Leake, 2007-04-22: > >> I'd like to add a new command to dvc-diff-mode-menu. >> This would be the command that means "get my workspace up-to-date >> with >> the parent". > [...] > > In the case with only one head, this is obviously what the user wants. > If there are multiple heads after the pull, what has happened could be > > (a) there was one local head and one remote head, both different and > neither an ancestor of the other > (b) there was one local head and multiple remote heads, the local head > being (an ancestor of) one of the remote heads > (c) there was one local head and multiple remote heads, the local head > not among (the ancestors of) the remote heads > (d) there were multiple local heads (even before the pull) and one > remote head, the remote head being (an ancestor of) one of the local heads > ...and so on, all combinations. > > Each of these cases differs as to how I want to merge, and what revision > I want to update to.
Right. Now that I've used monotone a little more, I can see that we don't want to automatically do any of these. >> We could have a single dvc command that does all of this. But maybe it >> would be better if the contents of dvc-diff-mode-menu were back-end >> dependent, and for bzr showed just 'bzr-merge', while for mtn showed >> all three steps independently. > > I haven't used the menus yet at all, so I have no opinion on whether it > would make sense to make them backend-dependent. I think the menus are the way that new DVC and monotone users will learn about what can be done. So they need to be good. And I'm pretty certain now that they need to be back-end dependent. > About the general idea of a combined "get my workspace up-to-date with > the parent" operation: With version control systems that heavily punish > divergence, you really need this, since it's an easy way to reduce the > likelihood of divergence. With monotone, my guess is that the utility > of such a command depends on your workflow. Right. -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
