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

[Derek Scherger]

graydon hoare wrote:
> > 1.  Should I have done monotone merge before trying to do monotone 
> > update or would that have done nothing for me in this case?
>
> not necessary, but legal. merge reduces multiple heads in your database 
> to a single head. update merges your working copy with the newest child 
> of the working copy base version. that will probably be *a* head of the 

When you say *a* head it sounds like it might be chosen at random, is that 
correct?
I think I do understand the merging of heads concept.

> > 2. It seems a bit odd to me (coming from cvs I guess) that monotone 
> > merge will make changes and commit them to my local db rather than 
> > just in my working copy. Probably I just don't understand what it's 
> > supposed do or how it works.
>
> yeah, it does feel weird, I'll grant. it deserves some documentation. 

I think the fact that I'm working against my own local db helps to justify that it's not 
as risky as it might sound. I can commit further work before pushing anything bad 
anywhere, even though the bad versions will also get pushed.

> remember that versions are identified by content, so if you merge the 
> same way I merge, we literally "get the same version" even though we did 

Yeah, and thats pretty damn cool I must say.

> > 3. It would probably be good to report what the problem was above 
> > (file configure.ac has conflicts and I have no conflict resolution 
> > tool installed) rather than failing with a not-so-helpful error.
>
> yeah. that's a bad error message. I've filed a bug.

There was almost no message at all really. I'll have to start looking at your 
bug database! ;)

> > 4. Would it be possible to have cvs style conflict markers rather than 
> > using xxdiff or emacs to resolve conflicts? Until I really get the 3 
> > way diff/merge stuff I'm not even sure this makes sense.

>   - you can always commit a working copy. always. there's no need to be
>     up to date. it's always a legitimate child of the parent it checked
>     out from, even if there are other children elsewhere.

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

> contrary arguments are something I'll listen to here, but I'm currently 
> not quite sold on the idea that merging "into" a working copy is a good 
> idea. perhaps some sort of compromise for special cases (restricting a 
> merge to a specific subtree or set of files?) would be sufficient. ideas?

I may be over-simplifying the problem, but here's what I'm thinking. xxdiff and emacs 
ediff are tools to merge things that require me to be involved and know how to use them. 
What if something like the cvs merge code existed as an alternative merge tool that 
operated without me being involved and simply left my working copy in a potentially bogus 
state (with conflict markers in conflicted files). I know how to resolve conflicts with 
the CVS markers in them and given that I don't really know what I'm doing with xxdiff or 
ediff odds are I'm going to screw up my file anyway and need to make further edits to fix 
it. Given this I'd probably configure my lua hooks to look for the cvs merge tool before 
xxdiff or ediff, at least until I figure them out a bit.

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?

> revert knows how to do single files. you have to say
>
>   "monotone revert <file> ..."
>
> did that not work?

I musta been asleep or something... I looked for that and apparently didn't see it. Works 
fine.

>> least). Another thought, can I simply remove the file and do another
>> update (cvs style revert)?

This didn't work very well... both monotone diff and status were quite unhappy with a 
missing file.

> > 6. The options for 3 way merge tools are xxdiff and emacs. I happen to 
> > use xemacs, which probably (?) has similar support as emacs does 
> > (ediff I expect). Should this also be considered as an option?
>
> sure. it's actually just a lua hook; you can define whatever you like 
> for the merger. if you have a bunch of preferred tools to try,

I'm starting to see how the hooks work so I now understand this a bit better and it makes 
sense. I may even work up a patch to include xemacs, once I have my 
"dont-clobber-existing-files-on-checkout" patch working.

> not at all. feedback is good; lets me know what needs polish (and 
> occasional wholesale replacement). thanks for playing with it. feel free 
> to file lots of bugs. worst case if I don't like them I'll just close 
> them :)

Will do... thanks for all the answers! I'm sure I'll have more questions.
--
Cheers,
Derek