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

Re: "svn: Won't delete locally modified directory ..."

From: Jeff Squyres <jsquyres_at_lam-mpi.org>
Date: 2004-06-28 17:28:51 CEST

On Wed, 23 Jun 2004, Jeff Squyres wrote:

> We'll try to collect this data if/when it happens again.

Ok, it happened again. Per our last exchanges, I think this is all the
information that you requested:

- Scenario: I have a local checkout of version r1478 (verified in the
   output below). I have no local modifications to the svn-controlled
   files in the tree, but I have built my software in this WC (this is
   important). I run "svn up" and get the "svn: Won't delete locally
   modified directory..." error.

- Before running "svn up", here's the output of "svn info ." from my WC:

Path: .
URL: svn+ssh://svn.open-mpi.org/l/svn/ompi/trunk
Repository UUID: 63e3feb5-37d5-0310-a306-e8a459e722fe
Revision: 1478
Node Kind: directory
Schedule: normal
Last Changed Author: gingery
Last Changed Rev: 1478
Last Changed Date: 2004-06-25 10:30:17 -0400 (Fri, 25 Jun 2004)
Properties Last Updated: 2004-06-17 09:56:14 -0400 (Thu, 17 Jun 2004)

- Before running "svn up", here's the output of "svnversion ." from my WC:

1478

- Before running "svn up", here's the output of "svn st -u" in my WC
   (note a few extra files in my tree that are ignored -- there's
   actually a bunch more that are hidden by svn:ignore):

        * 1478 src/mpi/c/get_version.c
        * 1478 src/mpi/f77/profile/Makefile.am
        * 1478 src/mpi/f77/win_delete_attr_f.c
? src/mpi/f77/foo.c
        * 1478 src/mpi/f77/request_free_f.c
        * 1478 src/mpi/checklist.txt
        * 1478 src/request/request.c
        * src/tools/openmpi/openmpi.c
        * src/tools/openmpi/Makefile.am
        * src/tools/openmpi/openmpi.h
        * src/tools/openmpi
        * src/tools/mpiexec
        * 1478 src/tools
        * 1478 src/rte
? src/mca/dynamic
? src/mca/ptl/make.out
        * 1478 src
? make.out
? config.out
Status against revision: 1486

- Note the src/rte change -- this is the deletion of the src/rte
   directory (it contains a subdirectory and some files in that
   subdirectory). This is evident below.

- When I run "svn up" in mv WC:

U src/mpi/c/get_version.c
U src/mpi/f77/win_delete_attr_f.c
U src/mpi/f77/request_free_f.c
U src/mpi/f77/profile/Makefile.am
U src/mpi/checklist.txt
U src/request/request.c
A src/tools/openmpi
A src/tools/openmpi/openmpi.c
A src/tools/openmpi/Makefile.am
A src/tools/openmpi/openmpi.h
A src/tools/mpiexec
svn: Won't delete locally modified directory 'src'
svn: Left locally modified or unversioned files

- When I run "svn st -u" after the update:

? src/mpi/f77/foo.c
? src/rte/universe
! * 1478 src/rte
? src/mca/dynamic
? src/mca/ptl/make.out
! * 1486 src
? make.out
? config.out
! 1486 .
Status against revision: 1486

- Notice that it claims that src/rte/universe is not under SVN control
   -- "universe" was one of the subdirectories that used to be
   contained in src/rte (and was under SVN control) -- it should have
   been deleted when src/rte was deleted, but there *were* locally
   modified files in there that do not show up because they are
   svn:ignore'd (specifically: Makefile and Makefile.in).

   So this looks to be a valid use of the error message, but it is
   definitely printing the *wrong* directory name (it should have said
   that src/rte/universe was not deleted because it contained locally
   modified files).

- So I ran "svn up" again, and got the same error message again:

svn: Won't delete locally modified directory 'src'
svn: Left locally modified or unversioned files

- I then ran "svn st -u" again -- notice that the output is different
   this time:

svn st -u:
? src/mpi/f77/foo.c
? src/rte
? src/mca/dynamic
? src/mca/ptl/make.out
! * 1486 src
? make.out
? config.out
! 1486 .
Status against revision: 1486

- So then I ran "sun up" a third time, and it finished successfully:

svn up:
  U src
  U .
Updated to revision 1486.

==================================================

So I think this was all triggered by "svn rm src/rte; svn ci src" (or
something similar to that). This, in turn, triggered the deletion of
src/rte/*, including src/rte/universe/*, which seemed to cause the
problems upon update for others.

Hence, this all seems to make perfect sense:

- The first time "svn up" fails, it's *really* complaining about
   src/rte/universe (because there are locally modified files in
   there), even though it claims it's complaining about "src".
   But it did succeed in removing src/rte/universe/.svn.

- The second time "svn up" fails, it ignores the src/rte/universe
   (because there's no longer an .svn in there -- I'm sure there's
   other, deeper reasons, but this is what the user can observe from
   the outside) and progresses on with the update, but then it's
   *really* complaining about "src/rte" (becase "universe" and other
   files are in there) even though it claims it's complaining about
   "src". It succeeds in removing src/rte/.svn.

- The third time, "svn up" completes because it has cleared
   src/rte/universe and src/rte, and can finish the update.

So I think this is really all about an incorrect error message.

This is also a repeatable problem. If I checkout r1478 and put a
non-svn-controlled file in src/rte/universe (eg., src/rte/universe/foo),
I can recreate the scenario:

------
shell$ svn co -r 1478 ...URL... ompi-r1478
[... lots of output ...]
shell$ cd ompi-r1478
shell$ touch src/rte/universe/foo
shell$ svn st -u
        * 1478 src/mpi/c/get_version.c
        * 1478 src/mpi/f77/profile/Makefile.am
        * 1478 src/mpi/f77/win_delete_attr_f.c
        * 1478 src/mpi/f77/request_free_f.c
        * 1478 src/mpi/checklist.txt
        * 1478 src/request/request.c
        * src/tools/openmpi/openmpi.c
        * src/tools/openmpi/Makefile.am
        * src/tools/openmpi/openmpi.h
        * src/tools/openmpi
        * src/tools/mpiexec
        * 1478 src/tools
? src/rte/universe/foo
        * 1478 src/rte
        * 1478 src
Status against revision: 1486
shell$ svn up
U src/mpi/c/get_version.c
U src/mpi/f77/win_delete_attr_f.c
U src/mpi/f77/request_free_f.c
U src/mpi/f77/profile/Makefile.am
U src/mpi/checklist.txt
U src/request/request.c
A src/tools/openmpi
A src/tools/openmpi/openmpi.c
A src/tools/openmpi/Makefile.am
A src/tools/openmpi/openmpi.h
A src/tools/mpiexec
svn: Won't delete locally modified directory 'src'
svn: Left locally modified or unversioned files
shell$ svn st -u
? src/rte/universe
! * 1478 src/rte
! * 1486 src
! 1486 .
Status against revision: 1486
shell$ svn up
svn: Won't delete locally modified directory 'src'
svn: Left locally modified or unversioned files
shell$ svn st -u
? src/rte
! * 1486 src
! 1486 .
Status against revision: 1486
shell$ svn up
  U src
  U .
Updated to revision 1486.
------

So it looks like this is the result of two factors:

1. An persistently incorrect error message (i.e., reporting the error in
the incorrect directory).

2. The fact that "svn up" stops after this error (which you indicated in
an earlier post has been fixed for svn 1.1).

So I think all of our confusion we because of #1. If you recall, my
prior posts were about svn complaining about the "src/mca" directory,
and you hypothesized that it was because svn was trying to remove and
re-create the src/mca directory, but I said that this should not be
possible -- the src/mca directory had not changed in quite a while.

But the directories below src/mca *had* changed. Hence, it wasn't
src/mca that was the problem -- it was something deeper under the
src/mca tree; we were looking in the wrong place.

Does this all make sense?

-- 
{+} Jeff Squyres
{+} jsquyres@lam-mpi.org
{+} http://www.lam-mpi.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 28 17:31:16 2004

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.