On Wed, Jul 15, 2009 at 08:17:55AM +0100, Barry Scott wrote:
> The attached script demonstrates what looks like a bug in subversion.
This is not a bug, but desired behaviour.
You're getting an out-of-date error because your command
sequence causes a tree conflict.
Below is the output of your script, with this diff applied:
--- svn-lose-properties.sh.orig 2009-07-15 12:20:29.000000000 +0100
+++ svn-lose-properties.sh 2009-07-15 12:32:38.000000000 +0100
@@ -32,6 +32,12 @@
svn rm working-copy/faildir/*
cp original-files/testdir/* working-copy/faildir/
svn add working-copy/faildir/*
+svn info working-copy
+svn info working-copy/testdir
+svn up working-copy
+svn status working-copy
+svn info working-copy
+svn info working-copy/testdir
svn commit working-copy -m"This breaks it"
test-working-copy faildir
and with ## comments added by me.
++ pwd
+ REPO_URL=file:///tmp/repository
+ rm -fr original-files repository working-copy
+ mkdir -p original-files/testdir
+ echo 'Not executable'
+ echo Executable
+ chmod +x original-files/testdir/file2
+ svnadmin create repository
+ svn import original-files file:///tmp/repository '-mInitial fileset - should be fine'
Adding original-files/testdir
Adding original-files/testdir/file1
Adding original-files/testdir/file2
Committed revision 1.
+ svn checkout file:///tmp/repository working-copy
A working-copy/testdir
A working-copy/testdir/file1
A working-copy/testdir/file2
Checked out revision 1.
+ test-working-copy testdir
+ test '!' -x working-copy/testdir/file1
+ test -x working-copy/testdir/file2
+ echo 'Spare file to match original misbehaviour'
+ svn add working-copy/testdir/file3
A working-copy/testdir/file3
+ svn commit working-copy '-mAdding third file'
Adding working-copy/testdir/file3
Transmitting file data .
Committed revision 2.
## After this, your entire working copy (with the exception
## of testdir/file3) is still at r1
+ test-working-copy testdir
+ test '!' -x working-copy/testdir/file1
+ test -x working-copy/testdir/file2
+ svn mv working-copy/testdir working-copy/faildir
A working-copy/faildir
D working-copy/testdir/file1
D working-copy/testdir/file2
D working-copy/testdir/file3
D working-copy/testdir
+ svn rm working-copy/faildir/file1 working-copy/faildir/file2 working-copy/faildir/file3
D working-copy/faildir/file1
D working-copy/faildir/file2
D working-copy/faildir/file3
+ cp original-files/testdir/file1 original-files/testdir/file2 working-copy/faildir/
+ svn add working-copy/faildir/file1 working-copy/faildir/file2
A working-copy/faildir/file1
A working-copy/faildir/file2
+ svn info working-copy
Path: working-copy
URL: file:///tmp/repository
Repository Root: file:///tmp/repository
Repository UUID: a4068836-7131-11de-a378-0d84915802e3
Revision: 1
## working-copy is at r1
Node Kind: directory
Schedule: normal
Last Changed Author: stsp
Last Changed Rev: 1
Last Changed Date: 2009-07-15 12:21:28 +0100 (Wed, 15 Jul 2009)
+ svn info working-copy/testdir
Path: working-copy/testdir
URL: file:///tmp/repository/testdir
Repository Root: file:///tmp/repository
Repository UUID: 35463714-7133-11de-b9ed-d19b206fba10
Revision: 1
## and so is working-copy/testdir
Node Kind: directory
Schedule: delete
Last Changed Author: stsp
Last Changed Rev: 1
Last Changed Date: 2009-07-15 12:32:41 +0100 (Wed, 15 Jul 2009)
## So committing won't work (since you're trying to modify
## working-copy/testdir at r1 which is already at r2 in the repository)
## So we update instead, and we get a tree conflict:
+ svn up working-copy
C working-copy/testdir
At revision 2.
Summary of conflicts:
Tree conflicts: 1
+ svn status working-copy
A + working-copy/faildir
M + working-copy/faildir/file1
MM + working-copy/faildir/file2
D working-copy/faildir/file3
D C working-copy/testdir
> local delete, incoming edit upon update
## What happened here?
## svn tried to update working-copy to r2 recursively.
## It tried to open testdir (which it determined to be at r1)
## in order to add file3 (adding/deleting files is "editing"
## a directory), which fails since you've locally renamed testdir.
## If you hadn't renamed testdir, svn would have bumped testdir
## to r2 after updating all of testdir's children to r2 as well.
D working-copy/testdir/file1
D working-copy/testdir/file2
D working-copy/testdir/file3
+ svn info working-copy
Path: working-copy
URL: file:///tmp/repository
Repository Root: file:///tmp/repository
Repository UUID: a4068836-7131-11de-a378-0d84915802e3
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: stsp
Last Changed Rev: 2
Last Changed Date: 2009-07-15 12:21:29 +0100 (Wed, 15 Jul 2009)
+ svn info working-copy/testdir
Path: working-copy/testdir
URL: file:///tmp/repository/testdir
Repository Root: file:///tmp/repository
Repository UUID: 6dd4fd6e-7132-11de-84d1-cf7d25ceaec5
Revision: 2
Node Kind: directory
Schedule: delete
Last Changed Author: stsp
Last Changed Rev: 2
Last Changed Date: 2009-07-15 12:27:08 +0100 (Wed, 15 Jul 2009)
Tree conflict: local delete, incoming edit upon update
Source left: (none) file:///tmp/repository/testdir_at_1
Source right: (dir) file:///tmp/repository/testdir_at_2
## Here we see r1 again.
+ svn commit working-copy '-mThis breaks it'
subversion/svn/commit-cmd.c:142: (apr_err=155015)
subversion/libsvn_client/commit.c:854: (apr_err=155015)
svn: Commit failed (details follow):
subversion/libsvn_client/commit_util.c:1057: (apr_err=155015)
subversion/libsvn_client/commit_util.c:522: (apr_err=155015)
subversion/libsvn_client/commit_util.c:298: (apr_err=155015)
svn: Aborting commit: '/tmp/working-copy/testdir' remains in conflict
So the out-of-date error you were seeing is really an
indicator that you should run 'svn update'.
Note that committing the deletion of an out-of-date item was
possible in Subversion < 1.6.0.
Stefan
Received on 2009-07-15 13:38:55 CEST