[Monotone-devel] Re: monotone update problem & associated questions

[graydon hoare]

Derek Scherger wrote:
> When you say *a* head it sounds like it might be chosen at random, is 
> that correct?

well, it might appear surprising, but it's quite deterministic. the 
update target is chosen in the following way.. hm, maybe I'll just draw 
a picture:

                /
               /
              [pre-update base version]
             /\
            /  [working copy]
           /
          [post-update base version]

becomes

                /
               /
              [pre-update base version]
             /
            /
           /
          [post-update base version]
           \
            [working copy]


that is, the update "moves" your working copy "down" the ancestry graph 
from where it started. it only considers heads which are descendents of 
the pre-update base version. if there are other heads (somewhere else) 
it ignores them. it also ignores disapproved, insufficiently trusted, or 
non-test-passing versions (subject to a hook).

if there are multiple candidates satisfying those criteria, the update 
fails, and you have to merge.

> Presumably doing so might get me into the multi-headed state then right? 
> And the fix for this is monotone merge. Seems fine.

yup. because there's no global synchronization, you (or anyone else) can 
always find yourself in a multi-head situation. it's nothing to worry 
about. the same is true in CVS, the multiple heads are just held in 
working copies and merged before committing. monotone just lets you 
commit first and merge later.

> I don't think monotone needs to know anything special in this case, I 
> can see the conflicts with monotone diff, and if I commit them too bad 
> for me, and anyone who gets my bad changes. CVS allows this to happen 
> and doesn't handle conflict markers particularly well. Perhaps not 
> handeling them at all is perfectly fine?
>
> Does this make any sense at all?

yeah, actually. that makes a lot of sense. thanks for taking the time to 
spell it out. the only reason it didn't make sense to *me* previously 
was that I had this over-general thought of extending the same mechanism 
for "general merges", which may have multiple parents. but you're right: 
both the pre and post-state for an update has a single parent, conflict 
markers or otherwise, so for updates it works fine. we should absolutely 
provide a standard hook to do this, maybe even wire the default hook to 
do so. it should work right away.

hm, I still do wonder if there's a way to phrase the task you perform 
with general merges in terms of updates to a working copy. people keep 
asking for this view of things, so I'd like to provide it (especially if 
it can be done easily).

-graydon