Re: [Monotone-devel] deleted files

[Brian May]

>>>>> "Daniel" == Daniel Carosone <address@hidden> writes:

    Daniel> Nope, alas.  The current merge algorithm for file
    Daniel> lifelines is one we call die-die-die merge, and it really
    Daniel> only knows about add and drop.

Ok, for now I will just re-add the files.

tailor called mtn to move a directory, and mtn failed for some unknown
reason, which resulted in the directory and all files being deleted
for some unknown reason.

2006-10-16 13:24:05     INFO: Changeset "Arch-1:address@hidden"
2006-10-16 13:24:05     INFO: Log message: Move user specific stuff to network 
dir
2006-10-16 13:24:05     INFO: Updating to u'Arch-1:address@hidden'
2006-10-16 13:24:06     INFO: /home/bam/monotone/config $ mtn drop --recursive 
user
2006-10-16 13:24:06     INFO: [Ok]
2006-10-16 13:24:06     INFO: /home/bam/monotone/config $ mtn rename user/brian 
network/default
2006-10-16 13:24:06  WARNING: [Status 1]
2006-10-16 13:24:06     INFO: /home/bam/monotone/config $ mtn commit --author 
"Brian May <address@hidden>" --date 2006-07-21T01:35:27 --message-file 
/tmp/bam/tailorWNGqTomtn .
2006-10-16 13:24:07     INFO: [Ok]

Come to think of it, I think I see why mtn failed (tailor didn't try
to move the files within the directory first).

I don't like programs that blindly continue after an error :-(.


Hmmm, now I get:

mtn: 2 heads on branch 'au.com.microcomaustralia.brian.config'
mtn: [left]  6f33a80d065d5a0033510a54841dc6b1c0d698f4
mtn: [right] 80e429a6ff5ab6d8e677173213616c344ca1355b
mtn: warning: rename target conflict: nodes 102, 98, both want parent 73, name 
default
mtn: warning: resolve non-content conflicts and then try again.
mtn: error: merge failed due to unresolved conflicts

Anyway of translating a node number into a full path?

    Daniel> Eventually, something like your idea may be the way this
    Daniel> is done.. to 'revive' a file, go back up in history to a
    Daniel> revision where the file was still alive, and commit a
    Daniel> child with some sort of "protect" or "undelete" or
    Daniel> "revive" operation.  When merging this new rev back to the
    Daniel> HEAD, the revive cancels the drop on the other side, and
    Daniel> provides a continuous ancestry path for the file.

Need to thing about this more. It sounds good in concept, but in
practise?

What would happen if you merged this branch into a branch where the
file never existed? Would this be allowed?

What happens if the file is deleted again? Would a future merge
operation "accidently" bring it back again?

    Daniel> Open questions include how to handle multiple
    Daniel> drop/revive/merge paths, especially where propagating
    Daniel> between several branches.  I'm sure a sensible solution
    Daniel> (essentially, merger behaviour for these operations) can
    Daniel> be designed, but noone has done so yet.
-- 
Brian May <address@hidden>