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" <abuchanan_at_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
Received on 2011-04-21 11:48:30 CEST