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". [...] > For monotone, the equivalent operation has three steps (I think; I > haven't actually used monotone much yet): > > mtn sync > mtn merge > mtn update > > 'mtn merge' will sometimes be unnecessary, if 'sync' has not created > any forks.
My experience with monotone is also limited, but I wouldn't want to run mtn merge unconditionally after pull, since there are some types of divergence that I don't want to resolve immediately. A more conservative approach would be mtn pull if only one head: update to it otherwise: pop to xmtn-view-heads-revlist 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. Case (a) is the only case where I usually want to merge everything and update to the resulting revision. In the cases where there already was divergence on the server, I don't necessarily want to resolve it -- someone else will probably take care of it, I don't want to duplicate the work. That's why I'd prefer to just see the heads in xmtn-view-heads-revlist and decide there whether and which ones I want to merge (using xmtn-revlist-explicit-merge), or whether I just want to pick one to continue working with (xmtn-revlist-update). Even in the case where there is only one head after the pull, just showing the revlist anyway (with no automatic update) would also be a reasonable option, since it's easy to trigger the update from the revlist buffer. This would arguably be more consistent. > 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. 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. It's probably useful if your pull operation is fast (e.g. if your mtn server is on a LAN), so I'm not opposed to implementing it. But I often just pull at arbitrary intervals and update independently of that; with remote servers, pull can take a little bit of time, and I don't usually want to wait just so I can stay fully in sync with the repository. I'd rather risk introducing some minor divergence. Christian. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
