Gunnar Dalsnes <har...@online.no> writes:
>>>
>>> REM tree conflict
>>>
>>> svn resolve --accept=working dir1
>> Did you miss a step?
> No, nothing is missed, but it seems this line is useless (but
> harmless). The problem appears regardless.
>> trunk2 is still an empty directory at r1, how can
>> that cause a conflict.
> Yes, just ignore that line.
I thought that was the conflict you were complaining about. I
misunderstood your email.
>>> svn up
>>>
>>> REM Updating '.':
>>> REM A dir1\file1.txt
>>>
>>> REM It says dir1\file1.txt is added, but it's nowhere to be seen
>>> dir dir1
>>> svn status dir1
>>>
>>> svn resolve --accept=working dir1
>>> svn revert dir1\file1.txt
>>>
>>> REM Nope, file is still deleted. Impossible to undelete it.
So here's my simple version:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/T
svn cp -mm file://`pwd`/repo/T ^/B
svn mkdir -mm file://`pwd`/repo/T/D
svn mkdir -mm file://`pwd`/repo/B/D
svn import -mm repo/format file://`pwd`/repo/B/D/f
svn co file://`pwd`/repo/B@2 wc
svn merge ^/T wc
svn up wc
svn st wc
What I see is:
svn st wc
M wc
R + C wc/D
> local add, incoming add upon update
D wc/D/f
Summary of conflicts:
Tree conflicts: 1
The merge creates an added directory wc/D (copied from /T/D in the
repo). This conflicts with the directory D added by the update (which
is /X/B in the repo) so a tree conflict is created. Note that wc/D is
marked as replaced. After accepting the working state:
svn resolve --accept working wc/D
I see:
svn st wc
M wc
R + wc/D
D wc/D/f
This is equivalent (ignoring the mergeinfo property) to
svn co file://`pwd`/repo/B
svn rm wc/D
svn cp ^/T/D wc/D
You can't revert wc/D/f without reverting the replace of wc/D.
--
Philip
