Re: tree conflict: new folder with old name

On Thu, May 27, 2010 at 12:55 PM, Ulrich Eckhardt
<eckhardt_at_satorlaser.com> wrote:
> On Thursday 27 May 2010, Giampiero Salvi wrote:
>> I know this is my fault, I'm just checking if there is a way to fix this.
>>
>> I renamed a folder and then created a new folder with the old name of
>> the first one:
>>
>> svn mv folder_name folder_name2008
>> svn ci -m "renamed folder_name"
>> mkdir folder_name
>> svn add folder_name
>> svn ci -m "added new folder with old name"
>
> Not beautiful, but not incorrect either.
>
>> Since this, I have been having "tree conflict" problems. I tried with
>> svn resolved which works at the moment I run it, but later I get the
>> conflict back.
>>
>>     C folder_name
>>     C folder_name2008
>> Updated to revision 1966.
>> Summary of conflicts:
>>    Tree conflicts: 2
>>
>> Is there a way I can bring the repository to a stable state again?
>
> The repository is stable, I think you mean the working copy. I guess that you
> have local, unversioned files in your local "folder_name". Those are not
> moved with the versioned files, so after the first step you have two folders.
> Then, the newly created versioned folder can't be created, because the local
> unversioned one is in the way.
>
> In any case, as with most problems with a working copy, just deleting it and
> checking out again typically does the job.

No, no, that's not necessary at all. Your working copy isn't corrupt,
you just have a tree conflict that you need to resolve, that's all.

I know tree conflicts can seem scary at first, but in reality it's not
that bad (ok, they are more difficult to resolve than text conflicts,
because you don't have a lot of help/tools to do it, but still). If
you search the archives of this list, you'll find some very useful
explanations about tree conflicts, and what you can do to remedy them.

Very broad principles:
- First find out the nature of the conflict, and try to understand why
it happened (see below for an explanation of why this tree conflict
happened in your case). You run "svn status" and "svn info <conflicted
item>" to get some useful information. If necessary run "svn log" on
the items involved to see what has happened to them.
- Then resolve the tree conflict to your satisfaction:
* If you think the current state of your working copy is "the way it
should be", just type "svn resolve --accept=working <conflicted
item>", and commit.
* If you think your actions were incorrect, and you should instead
accept the repository version: revert, update again, and all should be
fine.
* If it's a mix of the two, perform necessary actions to come to your
"merged" result, then "svn resolve --accept=working <conflicted
item>", and commit.

Now, why did you get this tree conflict in the first place? My guess
is that it's related to "mixed revision working copies". After 'svn ci
-m "renamed folder_name"', you should have done an 'svn update' of the
parent folder (or the entire working copy). That's needed to make the
parent dir aware of the new revision number (the one you just created
with your commit). Otherwise, it will complain about out-of-dateness
on the following tree-change you want to commit, you'll try to update,
and you get the tree conflict.

See the following issue for some more details:
http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of
newly added file followed by move (or delete) of parent dir causes
tree conflict

And this discussion on the dev list:
http://svn.haxx.se/dev/archive-2010-03/0495.shtml

Cheers,

-- 
Johan