I can reproduce this with current trunk.
Output immediately after the 'update' which introduces a conflict:
[[[
% svnqlite3-dump ../ | grep iota
INSERT INTO "ACTUAL_NODE"
VALUES(1,'trunk/iota','trunk',NULL,NULL,NULL,NULL,NULL,NULL,NULL,'(conflict
iota file update deleted edited (version file:///tmp/svn/r1 1 1 trunk/iota
file) (version file:///tmp/svn/r1 1 2 trunk/iota none))',NULL,NULL,NULL,NULL);
INSERT INTO "NODES"
VALUES(1,'trunk/iota',2,'trunk',1,'trunk/iota',1,'normal',NULL,NULL,'file',(),NULL,'$sha1$2c0aa9014a0cd07f01795a333d82485ef6d083e2',NULL,1,"Thu
Apr 21 07:30:46 2011",'daniel',25,"Thu Apr 21 07:30:48 2011",NULL,NULL);
INSERT INTO "NODES"
VALUES(1,'trunk/iota',0,'trunk',1,'trunk/iota',2,'not-present',NULL,NULL,'file',NULL,NULL,NULL,NULL,NULL,0,NULL,NULL,NULL,NULL,NULL);
% $svnversion
2M
% $svn st
A + C iota
> local edit, incoming delete upon update
Summary of conflicts:
Tree conflicts: 1
]]]
After reverting 'iota':
[[[
% $svn revert iota
Reverted 'iota'
% svnqlite3-dump ../ | grep iota
INSERT INTO "NODES"
VALUES(1,'trunk/iota',0,'trunk',1,'trunk/iota',2,'not-present',NULL,NULL,'file',NULL,NULL,NULL,NULL,NULL,0,NULL,NULL,NULL,NULL,NULL);
% $svnversion
2
% $svn st -q
% $svn st -v iota
? iota
]]]
I've used the following meta-recipe to reproduce:
[[[
create a greek tree working copy
cd wc1/trunk
$svn rm -q iota
echo alt > iota
$svn add -q iota
$svn ci -qm replace
$svn up -qr 1
echo mod >> iota
$svn up
]]]
On Wed, 20 Apr 2011 16:34 -0700, "Andrew Buchanan" <abucha...@grio.com> wrote:
> Hello all,
> I just got bitten by what looks like a bug in the handling of tree conflicts
> involving replaced files. To demonstrate:
> User A replaces foo.txt and commits their change:
> $ svn st -v
> R 4 4 abuchanan foo.txt
> $ svn commit -m 'replacing foo'
> Replacing foo.txt
>
> User B has modified foo.txt and gets a tree conflict when they svn up:
> $ svn up
> C foo.txt
> At revision 5.
> Summary of conflicts:
> Tree conflicts: 1
> $ svn st -v
> A + C - 4 abuchanan foo.txt
> > local edit, incoming delete upon update
>
> Knowing that their modifications can be discarded, user B tries to get
> things on track by reverting foo.txt.
> ***This results in their local foo.txt no longer being versioned and their
> working directory "forgetting" about the incoming replacement.***
> $ svn revert foo.txt
> Reverted 'foo.txt'
> $ svn st -v
> 5 5 abuchanan .
> ? foo.txt
> $ svn up
> At revision 5.
> $ svn st -v
> 5 5 abuchanan .
> ? foo.txt
> $
>
> foo.txt is in the repository, but svn up doesn't grab it. Deleting the now
> unversioned copy and running svn up with foo.txt as the explicit target will
> correctly check it out, but it can be hard to realize that something's
> missing when svn st and svn up of that directory say that everything's up to
> date.
>
> Thanks,
> -Andrew
>
