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
Received on 2011-04-21 04:15:48 CEST