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

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