You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeff Squyres <js...@lam-mpi.org> on 2004/06/17 18:18:33 UTC
"svn: Won't delete locally modified directory ..."
Greetings. I tried searching for this error around the subversion site
(bugs, mailing lists) and couldn't find it, so if this has come up before
and I simply missed it, please feel free to smack me with an "RTFM" and
point me in the right direction.
We've been using subversion happily ever since 1.0. However, one of our
projects has run into a lot of trouble in the past few days. It is now
not uncommon to have to "svn up" multiple times (e.g., 5 or 6 times)
before the full tree is updated. This is with both client and server
version 1.0.5 using svn+ssh:// kinds of repository URLs.
Here's a sample output:
-----
[...snipped previous normal update output...]
U mca/Makefile.am
svn: Won't delete locally modified directory 'mca'
svn: Left locally modified or unversioned files
Exit 1
earth[11:02]:~/ompi/src >svn update
svn: Won't delete locally modified directory 'mca'
svn: Left locally modified or unversioned files
Exit 1
earth[11:02]:~/ompi/src >cd mca/
earth[11:02]:~/ompi/src/mca >svn up
svn: Won't delete locally modified directory ''
svn: Left locally modified or unversioned files
Exit 1
earth[11:02]:~/ompi/src/mca >svn up
svn: Won't delete locally modified directory ''
svn: Left locally modified or unversioned files
Exit 1
earth[11:03]:~/ompi/src/mca >svn up
U .
Updated to revision 1360.
earth[11:03]:~/ompi/src/mca >
------
Note that the directory "mca" has *NOT* been deleted (nor should it be --
no one did "svn rm mca; svn ci mca"). So I'm not sure why the svn client
is complaing about not deleting it. But in addition to complaining about
it, it totally stops the "svn update" process. Hence, you have to run
"svn up" multiple times to get current (it *usually* seems to clear the
problem the next time you run "svn up", but see the above example where it
took 4 "sun up"'s to clear the problem in the "src/mca" directory).
This does not seem to be a race condition on the server; in this
particular example, all of my developers needed to run "svn up" 4 times to
clear the error (although some just did "rm -rf trunk; svn co ...."),
sometimes running a few hours after each other (i.e., I had to go explain
"run 'svn up' a few more times..." to each of them ;-) ).
We're not sure exactly what triggers this problem -- we have moved a few
files and directories in the past few days, as well as edit svn:ignore on
various directories. Could that have something to do with it?
Are we doing something wrong? (please feel free to ping me for more
information)
My developers are getting quite frustrated. I'm the local SVN evangelist
(SVN is great! CVS sucks! Woo hoo!), so I figured I'd ping this list and
see if anyone else has run into this problem.
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-06-28 at 18:16, Jeff Squyres wrote:
> On Mon, 28 Jun 2004, Ben Collins-Sussman wrote:
>
> > ...perhaps your 1.1 client is accidentally linking to an old libsvn_wc?
>
> Arrgh! I'm a dope. I even specifically configured the trunk statically
> to ensure that that wouldn't happen, but I had accidentally typed
> "--disable-share" instead of "--disable-shared", resulting in a
> shared-library version of svn (and therefore linking to the old .so's).
>
> Building it properly (statically), the trunk works nicely for me now, too.
>
> Thanks!
Thanks for your excellent research and diligence hunting this down,
Jeff. If only all bug reports were as thorough. :-)
And I'm glad 1.1 avoids this bug altogether. Phew.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Mon, 28 Jun 2004, Ben Collins-Sussman wrote:
> ...perhaps your 1.1 client is accidentally linking to an old libsvn_wc?
Arrgh! I'm a dope. I even specifically configured the trunk statically
to ensure that that wouldn't happen, but I had accidentally typed
"--disable-share" instead of "--disable-shared", resulting in a
shared-library version of svn (and therefore linking to the old .so's).
Building it properly (statically), the trunk works nicely for me now, too.
Thanks!
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-06-28 at 17:49, Jeff Squyres wrote:
> cd $HOME/checkout_number_1
> svn mkdir foo
> svn mkdir foo/bar
> svn ci -m "waaahoooo!"
>
> cd $HOME/checkout_number_2
> svn up
> touch foo/bar/baz
>
> cd $HOME/checkout_number_1
> svn rm foo
> svn ci -m "didn't want it anyway"
>
> cd $HOME/checkout_number_2
> svn up
> ==> error occurs
Um.... this recipe doesn't reproduce for me. I just built /trunk an
hour ago:
(I have wc and wc2 checkouts, each containing many files.)
[sussman@kepler:~/scratch]$ cd wc
[sussman@kepler:~/scratch/wc]$ svn mkdir foo
A foo
[sussman@kepler:~/scratch/wc]$ svn mkdir foo/bar
A foo/bar
[sussman@kepler:~/scratch/wc]$ svn ci -m "blah"
Adding foo
Adding foo/bar
Committed revision 23.
[sussman@kepler:~/scratch/wc]$ cd ../wc2
[sussman@kepler:~/scratch/wc2]$ svn up
A foo
A foo/bar
Updated to revision 23.
[sussman@kepler:~/scratch/wc2]$ touch foo/bar/baz
[sussman@kepler:~/scratch/wc2]$ cd ..
[sussman@kepler:~/scratch]$ cd wc
[sussman@kepler:~/scratch/wc]$ svn rm foo
D foo/bar
D foo
[sussman@kepler:~/scratch/wc]$ svn ci -m "bye"
Deleting foo
Committed revision 24.
[sussman@kepler:~/scratch/wc]$ cd ..
[sussman@kepler:~/scratch]$ cd wc2
[sussman@kepler:~/scratch/wc2]$ svn st -u
? foo/bar/baz
* 23 foo
Status against revision: 24
[sussman@kepler:~/scratch/wc2]$ svn up
D foo
Updated to revision 24.
[sussman@kepler:~/scratch/wc2]$ svn st
? foo
...perhaps your 1.1 client is accidentally linking to an old libsvn_wc?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Mon, 28 Jun 2004, Ben Collins-Sussman wrote:
>> Does this all make sense?
>
> Wow, Jeff, nice analysis!
Trying to atone for my prior lame "it doesn't work" messages. ;-)
> And now, here's the news: we're in process of freezing code for an svn
> 1.1 release. In svn 1.1, 'svn up' no longer stops dead in its tracks
> when it tries to remove a directory that contains unversioned stuff.
Yep -- you mentioned this before.
Any chance that the error message will be fixed to print the right
directory?
> It just leaves the unversioned stuff behind, and keeps going. This
> should, for all practical purposes, solve all the pain you've been
> experiencing. My recommendation, in fact, is that you checkout a copy
> of svn's /trunk code and try it out today.
Excellent suggestion; I just did that. Unfortunately, it still doesn't
work -- it both prints out the wrong directory name and bails on the first
"Won't delete..." error. :-(
Just to ensure I was running the right copy:
------
shell$ svn --version
svn, version 1.1.0 (dev build)
compiled Jun 28 2004, 18:37:20
-----
Here's a simple test case (even with the most recent svn trunk):
------
cd $HOME/checkout_number_1
svn mkdir foo
svn mkdir foo/bar
svn ci -m "waaahoooo!"
cd $HOME/checkout_number_2
svn up
touch foo/bar/baz
cd $HOME/checkout_number_1
svn rm foo
svn ci -m "didn't want it anyway"
cd $HOME/checkout_number_2
svn up
==> error occurs
------
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mon, 2004-06-28 at 10:28, Jeff Squyres wrote:
> 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?
Wow, Jeff, nice analysis!
And now, here's the news: we're in process of freezing code for an svn
1.1 release. In svn 1.1, 'svn up' no longer stops dead in its tracks
when it tries to remove a directory that contains unversioned stuff. It
just leaves the unversioned stuff behind, and keeps going. This should,
for all practical purposes, solve all the pain you've been
experiencing. My recommendation, in fact, is that you checkout a copy
of svn's /trunk code and try it out today.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
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
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Wed, 23 Jun 2004, Ben Collins-Sussman wrote:
> [snipped]
> That's not meant as an insult at all... I'm just at a loss as to how to
> help at this point.
>
> I guess I would recommend that you start collecting hard data to
> reproduce this bug:
> [snipped]
>
> When we have that, we can attempt to reproduce... we can look at server
> logs between rX:Y, and examine the working copy as well.
Understood, and no insult taken. Remember that a) I'm a software
developer, too, and b) I'm the local Subversion evangelist. :-)
We'll try to collect this data if/when it happens again. We've had a few
other minor errors about failed assertions in the svn client during "svn
up" when we've done a lot of moves of directories and files, but this was
before we started paying attention to these errors; if they happen again,
we'll hopefully have this kind of data to report.
Thanks.
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-06-23 at 10:17, Jeff Squyres wrote:
> This problem is that this is happening to a lot (read: all) of my
> developers -- including me (exactly the same scenario -- "svn up"
> complains about src/mca). So this is not unique to just one guy and his
> WC that got corrupted. Something in "svn up" is corrupting their WC's,
> specifically with regard to the src/mca directory.
So somehow, in the repository's history, the src/mca directory was
deleted and then replaced with a new object of identical name. Or so it
seems.
And somehow, a bunch of your users have working copies that believe
themselves to have the "old" src/mca object, rather than the "new" one.
At least that's the hypothesis.
>
> We have confirmed that getting a new checkout does not see this problem
> upon the initial checkout.
Great.
> But then the same kind of problem inevitably
> happens again later after some more "svn up"s (so far it has usually been
> with respect to the src/mca directory, but it has occassionally been with
> other directories as well -- but those were before I started recording the
> errors, and I don't have hard data on that).
The problem here is that
1. this is anecodal evidence, so it can't help us track down the
problem. We need a real recipe/script that demonstrates the problem.
2. this is problem seems to only be happening to your group. It's
not familiar-sounding at all.
I can promise you that if it were a common occurrence, it would long be
fixed by now. I agree, from your description, this is intolerable (and
seemingly nonsensical) behavior. But because we have no hard data to
reproduce, and because your group seems to be alone in experiencing it,
occam's razor makes me want to believe that there's some sort of unique
administrative configuration problem or user-process problem going on.
It's the simplest, most likely explanation.
That's not meant as an insult at all... I'm just at a loss as to how to
help at this point.
I guess I would recommend that you start collecting hard data to
reproduce this bug:
* have everyone do a fresh checkout and record the initial revision
they've checked out.
* before ever running 'svn up', run 'svn st -u' to preview the
update, and notice the HEAD revision they're about to receive.
* after running 'svn up', record the new revision they've updated to.
That way, the next time the bug comes up, your user can instantly grab
you and say, "hey, I had a working copy at revision X -- plus local mods
-- and then I attempted to update to revision Y, and poof, I got the
error."
When we have that, we can attempt to reproduce... we can look at server
logs between rX:Y, and examine the working copy as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Wed, 23 Jun 2004, Ben Collins-Sussman wrote:
>> ------------------------------------------------------------------------
>> r1443 | jsquyres | 2004-06-23 07:39:26 -0600 (Wed, 23 Jun 2004) | 3 lines
>> Changed paths:
>> M /trunk/src/mca/base/mca_base_module_find.c
>> M /trunk/src/mca/base/mca_base_modules_open.c
>>
>> Fix some more minor memory problems; convert some of the DSO loading
>> code to use OBJ_* things instead of manual malloc/free.
>>
>> ------------------------------------------------------------------------
>> shell$
>> -----
>>
>> The "svn log" shows that my developer is trying to get a change that I
>> committed this morning
>
> How do you know that? How do you know the working copy isn't extremely
> old, and server is trying to send multiple changesets, not just r1443?
I know/assume that because the "svn log -v -rHEAD" command that you
suggested a few days ago shows just that one changeset. He did get some
other changesets, too (please see the full transcript from my original
message).
> Whatever the case, the working copy told the server something that makes
> the server think that the 'mca' directory needs to be deleted and
> recreated.
Yes, and we don't know why. That directory has been around for quite a
long time and has not been deleted, renamed, or copied in the trunk for a
long, long time (specifically: these problems started about 2-3 weeks ago,
and it hasn't been renamed/copied/deleted/etc. since long before that).
> My guess is that either the working copy is really old, or got corrupted
> somehow. Run 'svnversion' on the working copy or 'svn st -v' to look at
> the mixed-revisions it contains.
I can do this, but I'm not sure what new information it will reveal.
He's got locally modified files, and only part of "svn up" completed. So
there will definitely be at least some files that show different r
numbers.
He was in the middle of an update that did get other changesets. At least
some of them seemed to go fine. Other than the "svn log" command that you
suggested, we don't know what other updates were not committed.
> More importantly, if you do a fresh checkout (create a new working copy)
> by running
>
> svn co trunkURL -r 1442
>
> followed by
>
> svn up
>
> Then I'm betting the update will only apply r1443, nothing else. In
> other words, there's something majorly wrong with the original working
> copy, not with the update process itself. Give it a whirl.
This problem is that this is happening to a lot (read: all) of my
developers -- including me (exactly the same scenario -- "svn up"
complains about src/mca). So this is not unique to just one guy and his
WC that got corrupted. Something in "svn up" is corrupting their WC's,
specifically with regard to the src/mca directory.
We have confirmed that getting a new checkout does not see this problem
upon the initial checkout. But then the same kind of problem inevitably
happens again later after some more "svn up"s (so far it has usually been
with respect to the src/mca directory, but it has occassionally been with
other directories as well -- but those were before I started recording the
errors, and I don't have hard data on that). It seems to happen randomly
(i.e., I can't predict when the next one will occur), but when it happens,
it happens to everyone who does "svn up".
Also, it's not always easy to just "get a new checkout" (and my developers
are getting quite tired of doing that -- "CVS never made us do that" is a
common complaint that I keep having to fend off). There can be lots of
uncommitted changes that would need to be ported to a new WC, potentially
including added and deleted files (e.g., "svn diff > $HOME/patchfile; cd
/some/new/WC; patch -p0 < $HOME/patchfile" is not always sufficient).
Got any other suggestions?
Thanks!
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-06-23 at 08:59, Jeff Squyres wrote:
> ------------------------------------------------------------------------
> r1443 | jsquyres | 2004-06-23 07:39:26 -0600 (Wed, 23 Jun 2004) | 3 lines
> Changed paths:
> M /trunk/src/mca/base/mca_base_module_find.c
> M /trunk/src/mca/base/mca_base_modules_open.c
>
> Fix some more minor memory problems; convert some of the DSO loading
> code to use OBJ_* things instead of manual malloc/free.
>
> ------------------------------------------------------------------------
> shell$
> -----
>
> The "svn log" shows that my developer is trying to get a change that I
> committed this morning
How do you know that? How do you know the working copy isn't extremely
old, and server is trying to send multiple changesets, not just r1443?
Whatever the case, the working copy told the server something that makes
the server think that the 'mca' directory needs to be deleted and
recreated.
My guess is that either the working copy is really old, or got corrupted
somehow. Run 'svnversion' on the working copy or 'svn st -v' to look at
the mixed-revisions it contains.
More importantly, if you do a fresh checkout (create a new working copy)
by running
svn co trunkURL -r 1442
followed by
svn up
Then I'm betting the update will only apply r1443, nothing else. In
other words, there's something majorly wrong with the original working
copy, not with the update process itself. Give it a whirl.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Fri, 18 Jun 2004, Jeff Squyres wrote:
>> [snipped]
>> That's not the only way 'mca' can be deleted. Remember that renames are
>> just copies + deletes. Why don't you run 'svn log -v -rHEAD
>> reposrootURL', and see exactly what changes are attempting to be merged.
>> The server really is trying to delete the 'mca' directory.
>
> The next time this happens, I will run "svn log ..." and send this
> additional information.
>
> FWIW, the "mca" directory (from the example in my prior mail) was not
> deleted or renamed (it's a pretty high-level directory in our source
> tree).
We have replicated this problem; here's what happened (these commands are
all run from the top-level directory of a
svn+ssh://machine/repoistory_name/trunk checkout):
------
shell$ svn up
A test/class/ompi_rb_tree.c
U test/class/Makefile.am
U test/class
U src/event/Makefile.am
[...snipped more normal update stuff, nothing from src/mca yet....]
U src/request/request.c
U src/request/request.h
U src/mca/ptl/elan/configure.params
U src/mca/ptl/elan/src/ptl_elan_init.c
U src/mca/ptl/elan/src/ptl_elan_frag.h
U src/mca/ptl/elan/src/ptl_elan_priv.h
U src/mca/ptl/elan/src/ptl_elan.h
U src/mca/ptl/elan/src/ptl_elan_module.c
U src/mca/ptl/elan/src/Makefile.am
U src/mca/ptl/elan/Makefile.am
U src/mca/ptl/elan/configure.stub
svn: Won't delete locally modified directory 'src/mca'
svn: Left locally modified or unversioned files
shell$ svn cleanup
shell$ svn up
svn: Won't delete locally modified directory 'src/mca'
svn: Left locally modified or unversioned files
shell$ svn log -v -rHEAD
------------------------------------------------------------------------
r1443 | jsquyres | 2004-06-23 07:39:26 -0600 (Wed, 23 Jun 2004) | 3 lines
Changed paths:
M /trunk/src/mca/base/mca_base_module_find.c
M /trunk/src/mca/base/mca_base_modules_open.c
Fix some more minor memory problems; convert some of the DSO loading
code to use OBJ_* things instead of manual malloc/free.
------------------------------------------------------------------------
shell$
-----
The "svn log" shows that my developer is trying to get a change that I
committed this morning -- I did not change the properties on src/mca,
delete it, branch/copy it, etc. It's just two files within a
subdirectory of src/mca (specifically, src/mca/base).
Are we doing something wrong?
We have found that repeatedly running "svn cleanup; svn up" will clear
the problem -- but sometimes it has to be run tens of times. So we
have a script:
-----
#!/bin/csh
set done=0
while ($done == 0)
echo running cleanup/up
svn cleanup
svn up
if ($status == 0) then
echo "svn up was happy -- whoo hoo!"
set done=1
endif
end
-----
Clearly, this is sub-optimal, but it's better than removing your entire WC
when you have lots of changes that you don't want to ditch. ;-) Indeed,
you can't necessarily get a coherent "svn diff" and patch that onto a new
WC because you may potentially have an inconsistent checkout at this
point.
Any suggestions would be greatly appreciated.
Many thanks!
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Jeff Squyres <js...@lam-mpi.org>.
On Fri, 18 Jun 2004, Ben Collins-Sussman wrote:
>> Note that the directory "mca" has *NOT* been deleted (nor should it be --
>> no one did "svn rm mca; svn ci mca").
>
> That's not the only way 'mca' can be deleted. Remember that renames are
> just copies + deletes. Why don't you run 'svn log -v -rHEAD
> reposrootURL', and see exactly what changes are attempting to be merged.
> The server really is trying to delete the 'mca' directory.
The next time this happens, I will run "svn log ..." and send this
additional information.
FWIW, the "mca" directory (from the example in my prior mail) was not
deleted or renamed (it's a pretty high-level directory in our source
tree).
>> But in addition to complaining about
>> it, it totally stops the "svn update" process. Hence, you have to run
>> "svn up" multiple times
>
> This behavior has been fixed in svn 1.1 (the latest /trunk code). If
> the update process tries to delete a file or directory which contains
> local modifications, it no longer stops dead in its tracks. Instead, it
> just 'unversions' the locally modified object and keeps going. After
> the update completes, 'svn status' shows unversioned objects.
Excellent; that will be great.
Thanks!
--
{+} 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
Re: "svn: Won't delete locally modified directory ..."
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-06-17 at 13:18, Jeff Squyres wrote:
> Note that the directory "mca" has *NOT* been deleted (nor should it be --
> no one did "svn rm mca; svn ci mca").
That's not the only way 'mca' can be deleted. Remember that renames are
just copies + deletes. Why don't you run 'svn log -v -rHEAD
reposrootURL', and see exactly what changes are attempting to be
merged. The server really is trying to delete the 'mca' directory.
> But in addition to complaining about
> it, it totally stops the "svn update" process. Hence, you have to run
> "svn up" multiple times
This behavior has been fixed in svn 1.1 (the latest /trunk code). If
the update process tries to delete a file or directory which contains
local modifications, it no longer stops dead in its tracks. Instead, it
just 'unversions' the locally modified object and keeps going. After
the update completes, 'svn status' shows unversioned objects.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org