[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] deleted files
From: |
Brian May |
Subject: |
Re: [Monotone-devel] deleted files |
Date: |
Mon, 16 Oct 2006 15:49:43 +1000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) |
>>>>> "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>