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

[graydon hoare]

Derek Scherger 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 
branch, but if there are multiple heads you might want to merge them 
into one first before updating.

> 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've filed a doc bug to try to clarify this: merge attempts to work "as 
algorithmically as possible", because it increases the chance that you 
will have a merge result in common with another user who does the same 
merge. the more nodes you have in common with other users, the better.

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 
not communicate or coordinate. the emphasis on algorithmic merging is 
intended to increase the chance of that happening. if there is something 
"wrong" with the merge, you can always commit a fix post-merge.

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

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

it makes sense, yes. but it requires putting more state into the working 
copy, in a way I'd somewhat prefer not to do. I'll explain how things 
currently are, and you can tell me how you'd prefer them to be.

  - we don't have any concept of a working copy holding a
    merge-in-progress. there's nothing marking files as holding a
    conflict either.

  - a working copy has simple semantics: it is a single manifest + a
    child-in-progress, with a degenerate case where there are no
    changes made yet.

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

  - you only update when you *want* to do merging work, not (as in CVS)
    when the VC system tells you to. if you don't want to do merging
    work, just commit what you have. someone else can do your merge
    later.

  - divergence is something monotone doesn't fight. it gives people
    tools to reduce it, when they want to. but it doesn't force
    serialization.

now, it's possible to change the semantics of a working copy. it would 
be some work, but it's possible. we'd need to make the working copy hold 
pointers to multiple manifests (the multiple parents contributing to a 
merge) and some sort of stored indicator showing that a file has 
conflicts. that would make it feel more CVS-like (and SVN-like, and 
arch-like...) so there's an argument in favour of it.

there are two arguments against it:

 1. as I said above, monotone was designed to try to make it likely that
    people will synthesize identical algorithmic merges. this will
    happen less when there's activity in a working copy. but then, if
    you need to commit new fixups after a merge, that's new divergence,
    so I'm not completely convinced of my own line of reasoning here.

 2. it's a lot of new code. a bunch of commands become more complex in
    the multi-way-merge case in a working copy (eg. what does "diff"
    or "revert" do?) and there's a bunch of new files in the working
    copy which need to be kept consistent (or handled when they're not).

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?

> 5. Now that my conflict has been resolved by xxdiff, even though I 
> actually intended not to resolve it, it would be good to be able to 
> revert a single file rather than my entire working copy. It appears that 
> revert currently does not allow this and will revert my entire tree, but 
> it seems like it should be easy to do (conceptually at least). Another 
> thought, can I simply remove the file and do another update (cvs style 
> revert)?

revert knows how to do single files. you have to say

  "monotone revert <file> ..."

did that not work?

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

> 7. While xxdiff was running my database was apparently locked and 
> attempts to execute other monotone commands failed somewhat miserably. 
> It would be good (from my perspective at least) to report some useful 
> error message. It's probably fine not to handle multiple processes 
> working with the db at the same time though. (I seem to remember seeing 
> a comment to this effect with a "... you get what you pay for" tacked on 
> the end of it ;) )

yeah, the error message there isn't good. on my system it seems to 
misinterpret the locking as a malformed db image. odd. I'll file a bug 
on that.

> 8. When updating my working copy, is the entire update an atomic 
> operation, or does each file update represent it's own little filesystem 
> transaction?

the merging portion of the update is all done in memory and temp files. 
if you abort the process during the merging phase, nothing happens. once 
all merge decisions are made, the files are all written out to the 
working copy en masse. the write-out process is not strictly atomic 
(though each file is written fully first and then rename(2)'ed into 
place), so there's a small race in there where you could interrupt the 
process and leave your tree only partly updated. say only half the 
merged files being written out.

if you did that, however, you'd at worst leave some files updated and 
some not. if you run update again, it'll read the manifest, compare to 
the (un-updated) files in the working copy, and finish the job.

> I Hope I'm not overwhelming you with feedback! I'm actually liking 
> montone a lot.

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

-graydon