You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew Buchanan <ab...@grio.com> on 2011/04/21 01:34:29 UTC
BUG Tree conflict + revert leads to missing/forgotten file
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
Re: BUG Tree conflict + revert leads to missing/forgotten file
Posted by Stephen Butler <sb...@elego.de>.
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" <ab...@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
Re: BUG Tree conflict + revert leads to missing/forgotten file
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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" <ab...@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
>