monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] update --move-conflicting-paths


From: Stephen Leake
Subject: [Monotone-devel] update --move-conflicting-paths
Date: Thu, 06 Aug 2009 19:22:33 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt)

I'm working on getting the --move-conflicting-paths option ready to
promote to main. It's currently on branch
nvm.experimental.remove_leftover_files. 

There was discussion on this almost a year ago; see
http://lists.gnu.org/archive/html/monotone-devel/2008-09/msg00071.html 

It was moving conflicting files to
_MTN/conflicts/<date-time>/<workspace_path>. That doesn't work on
Windows, because the date-time format has colons in it.

For the moment, I've changed this to _MTN/resolutions/<workspace_path>
. I use that same directory for conflict resolution stuff from Emacs
dvc, so it all gets cleaned up together.

I'm not clear why the <date-time> was considered necessary. Recently,
Thomas Keller suggested replacing it with the revision id. That would
at least solve the Windows path problem. But I'm not clear what
problem there is with just _MTN/resolutions/<workspace_path>. 

A simple example is (taken from tests/move_conflicting_unversioned):

addfile("somefile", "somefile content")
mkdir("somedir")
addfile("somedir/anotherfile", "anotherfile content")
commit("testbranch", "base")
base = base_revision()

addfile("thirdfile", "thirdfile content")
addfile("somedir/fourthfile", "fourthfile content")
commit("testbranch", "one")
rev_one = base_revision()

revert_to(base)
writefile("thirdfile", "thirdfile content 2")
writefile("somedir/fourthfile", "fourthfile content 2")

-- reports conflicts with unversioned files
check(mtn("update"), 1, nil, true)
check(qgrep("unversioned", "stderr"))

-- moves them out of the way
check(mtn("update", "--move-conflicting-paths"), 0, nil, true)
check(qgrep("moved conflicting", "stderr"))
check(readfile("_MTN/resolutions/somedir/fourthfile")=="fourthfile content 2")

This leaves the user file _MTN/resolutions/somedir/fourthfile.

That would need a "better" name if there is a use case that would try
to move a file with the same workspace path there again (assuming the
user forgets to clean up). I can't think of a reasonable use case that
does that.

Any suggestions?

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]