[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: mtn: misuse: rename target 'Foo/bla' already ex
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Re: mtn: misuse: rename target 'Foo/bla' already exists |
Date: |
Tue, 23 Sep 2008 19:21:43 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) |
Boris <address@hidden> writes:
>> [...]You can check out the _other_ revision in a separate workspace to
>> compare them.
>>
>> This is a case where "show conflicts" would help, _if_ it could show
>> workspace conflicts.
>>
>>> Before I mess up everything and lose revisions maybe someone can tell
>>> me how I can proceed safely? I'm using monotone 0.40 (both on Windows
>>> XP and Cygwin).
>>
>> You have a conflict; revision '4e34de' has a file named Foo/bla, but
>> the workspace has an _unknown_ file Foo/bla as well.
>
> I'd be surprised if it's unknown: Foo/bla is a directory which has
> been added to the project a long time ago. On my Windows computer
> it's called however Foo/Bla. Is it possible that this problem is
> related with case sensitivity?
yes, that can be a problem. I also share a mtn project between a
case-sensitive and case-insensitive system, and the only safe way I've
found to operate is insist on all file names being lowercase (with a
very few exceptions for Makefiles and such that have traditional case).
>> The simplest way to proceed is to move the workspace file Foo/bla to
>> somewhere else, outside the workspace. Then do the update, then use
>> your favorite merge tool to merge the known Foo/bla with the unknown
>> Foo/bla.
>
> Thanks, I did this. I compared then the directories with each other:
> All files are identical (no new or dropped files either).
>
> With 'mtn heads' I'm now told that the branch is merged. However when
> I try 'mtn update' I get now this error message:
>
> mtn: updating along branch 'mybranch'
> mtn: selected update target 4e34dedb6e8a9cb16f3a303b86c61fd384328e42
> mtn: [left] 5a641ac778ae8acab3f1415febc4582bc9204810
> mtn: [right] 4e34dedb6e8a9cb16f3a303b86c61fd384328e42
> mtn: error: workspace is locked
> mtn: error: you must clean up and remove the _MTN/detached directory
>
> When I check _MTN/detached I find two files called "2" and "3" which
> are the header and .cpp file of a class which isn't used anymore. The
> header and .cpp file doesn't exist in my workspace anymore. If I try
> to drop them with 'mtn drop' monotone tells me "not currently
> tracked".
Do they exist in the revision you are trying to update to?
> I've checked out now the right side - same problem:
>
> mtn: expanded selector '4e34dedb6e8a9cb16f3a' -> 'i:4e34dedb6e8a9cb16f3a'
> mtn: expanding selection '4e34dedb6e8a9cb16f3a'
> mtn: expanded to '4e34dedb6e8a9cb16f3a303b86c61fd384328e42'
> mtn: misuse: rename target 'Foo/bla' already exists
Was this a checkout into a totally new directory? If so, this sounds
like you actually have two directories in the latest database
revision; Foo/bla and Foo/Bla.
On a case-sensitive file system, they can both be checked out. On a
Windows system, they can't. Update of an existing workspace is not the
issue.
So you need to rename or drop one of them, on the case-sensitive
system. Then see if you can checkout on the case-insensitive system.
>> [...]This is discussed in the monotone manual, in the section Advanced
>> Uses | Workspace Collisions, and the second option in Advanced Uses |
>> Merge Conflicts. Can you suggest improvements to those sections that
>> would have helped you with this?
>
> I've been searching for "already exists" in the manual (as the error
> message I get is "rename target 'Foo/bla' already exists"). I found
> one match but not an explanation for the error message. I'll have a
> look at the section but recommend to put the error message(s)
> somewhere there (that would have helped me to find that part of the
> document :).
That's a good idea, but somewhat difficult. There are a _lot_ of error
messages, and most are translated to the user's locale. I don't think
it's feasible to try to put all of them in the manual.
It would help if the error message started with 'conflict:'; then you
could search for "conflict" in the manual.
--
-- Stephe