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

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
Received on Wed Jun 23 18:32:16 2004