On Wed, 2009-08-12, Vincent Lefevre wrote:
> Another nasty bug in Subversion that leads to a working copy
> with missing data and an inconsistent state...
>
> To reproduce it, consider the following script (run it from
> an empty directory):
I tested with a build from the 1.6.x branch, around 2009-07-15.
> ----------------------------------------
> #!/bin/sh
>
> set -ex
>
> svnadmin create svn
> svn co file://`pwd`/svn wc1
> cd wc1
> touch foo
> svn add foo
> svn ci -m 'added foo'
> svn cp foo bar
> echo blah >> bar
> svn ci -m 'foo -> bar'
> cd ..
> svn co file://`pwd`/svn_at_1 wc2
> cd wc2
> svn cp foo bar
Up to this point, all is well. From here on, I tried the following:
[[[
$ svn up
C bar
At revision 2.
Summary of conflicts:
Tree conflicts: 1
$ svn info . bar
Path: .
URL: file:///home/julianfoad/tmp/svn/lefevre1/svn
Repository Root: file:///home/julianfoad/tmp/svn/lefevre1/svn
Repository UUID: 6b5b6ded-0471-0410-bc99-6fa21c3cb954
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: julianfoad
Last Changed Rev: 2
Last Changed Date: 2009-08-13 13:18:07 +0100 (Thu, 13 Aug 2009)
Path: bar
Name: bar
URL: file:///home/julianfoad/tmp/svn/lefevre1/svn/bar
Repository Root: file:///home/julianfoad/tmp/svn/lefevre1/svn
Revision: 1
Node Kind: file
Schedule: add
Copied From URL: file:///home/julianfoad/tmp/svn/lefevre1/svn/foo
Copied From Rev: 1
Checksum: d41d8cd98f00b204e9800998ecf8427e
Tree conflict: local add, incoming add upon update
Source left: (none)
file:///home/julianfoad/tmp/svn/lefevre1/svn/bar_at_1
Source right: (file)
file:///home/julianfoad/tmp/svn/lefevre1/svn/bar_at_2
]]]
First question: is 'bar' still meant to be at revision 1 here, before we
resolve the conflict? I can't remember how we intended this to work.
Then:
[[[
$ svn resolved bar
Resolved conflicted state of 'bar'
$ svn info . bar
Path: .
URL: file:///home/julianfoad/tmp/svn/lefevre1/svn
Repository Root: file:///home/julianfoad/tmp/svn/lefevre1/svn
Repository UUID: 6b5b6ded-0471-0410-bc99-6fa21c3cb954
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: julianfoad
Last Changed Rev: 2
Last Changed Date: 2009-08-13 13:18:07 +0100 (Thu, 13 Aug 2009)
Path: bar
Name: bar
URL: file:///home/julianfoad/tmp/svn/lefevre1/svn/bar
Repository Root: file:///home/julianfoad/tmp/svn/lefevre1/svn
Revision: 1
Node Kind: file
Schedule: add
Copied From URL: file:///home/julianfoad/tmp/svn/lefevre1/svn/foo
Copied From Rev: 1
Checksum: d41d8cd98f00b204e9800998ecf8427e
]]]
Second point: I'm pretty sure 'bar' should not still be at revision 1
here, after we resolve the conflict.
Then:
[[[
$ svn up
At revision 2.
$ svn info . bar
[nothing changed - same output as above]
]]]
Oops. The update did nothing, even though 'bar' is locally still at
revision 1. Is there some meta-data affecting this that we cannot see in
the 'info' command? This looks like a bug in "update".
Then:
[[[
$ svn up bar
C bar
At revision 2.
Summary of conflicts:
Tree conflicts: 1
]]]
That's an example of the infamous 'merry-go-round' situation. The
previous steps should work in such a way that we do not reach this
point.
- Julian
> + svn up
> C bar
> At revision 2.
> Summary of conflicts:
> Tree conflicts: 1
> + svn resolved bar
> Resolved conflicted state of 'bar'
> + svn revert bar
> Reverted 'bar'
> + svn up
> At revision 2.
> + svn st -u
> ? bar
> Status against revision: 2
> + svn ls -v
> 2 vlefevre Aug 12 18:02 ./
> 2 vlefevre 5 Aug 12 18:02 bar
> 1 vlefevre 0 Aug 12 18:02 foo
> + ls -l
> total 0
> -rw-r--r-- 1 vlefevre vlefevre 0 2009-08-12 18:02:40 bar
> -rw-r--r-- 1 vlefevre vlefevre 0 2009-08-12 18:02:39 foo
>
> As you can see, the working copy is declared to be up-to-date,
> but its contents don't match those of the repository.
>
> This bug occurs with:
>
> svn, version 1.6.4 (r38063)
> compiled Aug 6 2009, 20:17:47
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383266
Received on 2009-08-13 14:39:43 CEST