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

[Derek Scherger]

graydon hoare wrote:

> 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.

OK, that all now makes perfect sense. It's not random at all, there can only be one head 
that's valid or it fails. "In the end there can be only one..."

I have more questions along the lines of disapproved, untrusted and failing versions too 
but I'll save them for another day so that we can stay somewhat on the topic of merging 
here. ;)

> 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.

Now all that we need to do is extract the cvs merge and conflict marking code into a stand 
alone program, that could be some fun. I guess I've got to quit talking and start doing 
one of these days!

I actually wish that unix patch command could merge like this too, now that I think about 
it, rather than creating .rej files all over the place. It's pretty easy to grep for 
^(<<<|>>>|===) to see where the conflicts are. Perhaps a more definitive conflict marker 
is all that's needed to be able to provide a monotone conflicts command that lists 
conflicted files by simply looking for the marker.

> 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).

You're talking about the monotone merge command right? As I understand it this only does 
something where there are multiple heads (unmerged children of some ancestor) right. And 
if there are several heads of some ancestor you merge them 2 at a time until there is only 
one. If these aren't true statements then the following is likely to be pretty bad.

If you were using something like the cvs merge code to do this to a working copy rather 
than directly in the db it seems like it should be able to work. For starters, let's skip 
the case where the working copy has pending changes in it and assume it has not been 
modified since being checked out. One head of some unmerged file is in the working copy 
and the rest are in the db. Doing a merge needs to select one of these heads and merge it 
in as an update would. If there are any conflicts it's probably time to stop and let the 
user fix them before continuing. If not, it should be able to grab the next head and keep 
going. After merging each head I assume you'll need to record the additional ancestor cert 
somewhere. Can you do this in the working copy anywhere or do the certs only ever exist in 
the database?

If this all works, is anything different when working copy has pending changes? It seems 
like it's probably exactly the same.

Also, it seems like I should be able to merge in some heads and commit that without 
merging in *all* of the heads. Although, in my case above the only way it will stop is 
when there's a conflict. Perhaps instead it only ever merges one head so that I can commit 
some progress towards merging a bunch of heads back together. It might be good to be able 
to specify which head (or heads) I want to merge but then there needs to be some way to 
see what the heads are all about.

There's probably no reliance at all on using the cvs merge code in this way either and it 
should be the same with xxdiff, emacs or whatever.

I wonder what a diff would look like when I've merged in some of the heads? What would I 
be diffing against? Is this where your "multiple parents" comment above comes in?

Hopefully all this helps, and I'm not just stating things that are obvious.
--
Cheers,
Derek