On Apr 21, 2011, at 6:36 , Daniel Shahaf wrote: > I can reproduce this with current trunk.
This looks like issue 3569 "svn update --depth <DEPTH> allows making a working copy incomplete". http://subversion.tigris.org/issues/show_bug.cgi?id=3569 The issue lists two ways to trigger the bug: 1. "svn up --depth" where depth < wc-depth 2. revert the victim of a tree conflict (local edit, incoming replacement) Steve > > 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 >> -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
