[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Commit fails after delete then add sequence

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 15 Jul 2009 12:37:25 +0100

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.