Re: [Monotone-devel] Mark merge for existence

[Markus Schiltknecht]

Hey William,

William Uther wrote:
>   As a first step I'd like to make a version of monotone that remembers 
> the new 'existence' marks when the file exists (i.e. add existence marks 
> to the current code without trying to remember them when a file is 
> deleted - no it wont change anything, but it is a necessary step).

"The" new existence marks? Did I miss something here?

Are you sure, that's the solution to the die die die merge problem? I'd 
rather add an (async) copy command (which does not track merges). And 
try to get merging right for it. I.e.  (uppercase letters are revisions, 
numbers represent node ids):

           A(1,2,3)
           /     \
          /       \
      B(1,3,4)   C(1,2,3,5=copy(2))
          \       /
           \     /
          D(1,3,4,5=copy(2 at A))


That would solve half of the mtn copy game *and* give us a good tool 
against die die die.

Just my line of thinking...

>   The problem is that there seem to be a couple of different places that 
> marks and rosters are generated / merged and I want to make sure I 
> understand what is going on before I play with things - this is fairly 
> important code. :)
>
>   Let's consider the call chain following the "merge" command [I've 
> included only one branch in the call chain where 
> interactive_merge_and_store() calls roster_merge() then 
> store_roster_merge_result()]:
>
>   cmd_merging.cc : CMD(merge)
>   cmd_merging.cc : merge_two()
>   merge.cc : interactive_merge_and_store()   # loads the left & right 
> rosters and marks from db
>   roster_merge.cc : roster_merge()         merge.cc : 
> store_roster_merge_result()
>                                            database.cc : 
> database::put_revision()
>                                            database.cc : 
> put_roster_for_revision()
>                                            roster.cc : 
> make_roster_for_revision()
>                                            roster.cc : 
> make_roster_for_merge()
>                                            roster.cc : 
> mark_merge_roster()  # much happens here
>                                            roster.cc :  
> mark_unmerged_node()  and  mark_merged_node()
>
>   It seems that roster_merge() does the main merge, but then 
> mark_merge_roster() does a lot of very similar work to build up the new 
> marking map just before it is actually written to the db.  This seems a 
> little convoluted.  Is there some reason for this I'm missing, or is it 
> just... historical?
>
>   That means that if I want to add new existence marks, I'd need to add 
> them both in roster_merge() and in mark_merge_roster().  Are there any 
> other places I should look at?
>
>   Oh, and I've had to change things like roster.cc:push_marking().  I'd 
> prefer to update some database format ID so that I don't get my db's all 
> confused while working on different versions of MTN.  Where would I find 
> that in the code?
>
> Cheers,
>
> Will        :-}
>
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel