Question

I’ve somehow managed to get an SVN repository into a bad state. I’ve moved a directory and now I can’t commit it in its new location.

As far as svn status is concerned, the directory is unknown (the name of the directory is type).

 $ svn status ?      type 

When I try to add the directory, the server says it already exists.

 $ svn add type svn: warning: 'type' is already under version control 

If I try to update the directory, it’s gone again.

 $ svn update type svn: '.' is not under version control 

If I try to commit it, the server complains that it’s old parent directory no longer exists.

 $ svn commit type -m 'Moving type' svn: Commit failed (details follow): svn: '/prior/trunk/src/nyu/prior/cvc3/theorem_prover/expression' path not found 

To add to the mystery, the contents of the directory are marked as modified.

 $ svn status type A  +   type M  +   type/IntegerType.java M  +   type/BooleanType.java M  +   type/Type.java M  +   type/RationalRangeType.java M  +   type/RationalType.java M  +   type/IntegerRangeType.java 

If I try to update from within the directory, I get this.

 $ cd type $ svn update svn: Two top-level reports with no target 

Committing from within the directory gives the same path not found error as above.

What’s going on and how do I fix it?

EDIT: @Rob Oxspring caught me out: I got too aggressive moving things around in Eclipse.

UPDATE: I’m accepting @Rob Oxspring’s answer of ‘don’t do that/just start over’ and taking his advice. I’d still be interested if anybody could tell me: (a) what the above error messages mean precisely and (b) how to actually fix the problem.

Answer 1

It looks to me like type was created by some Subversion-aware copy command, then moved into the current directory using a Subversion-unaware copy. In my experience, this sort of thing typically occurs when package refactoring operations have been chained together in Eclipse without commits in between. Typically, Subversion doesn’t handle it well when you copy/move a locally copied/moved file or folder, although I think version 1.5 may handle it better.

To avoid this in the future, commit between such steps. If you’d like to hide the intervening commits then I’d recommend doing the multi-step refactoring on a branch and then merging the changes back into the mainline in that single commit you were after.

If it’s not too much work, then I’d recommend getting back to a clean working copy and redoing your changes, committing after each step. If you’re happy to lose the history, i.e. allowing the new IntegerType.java to not be linked at all to the old IntegerType.java, then you could take the approach suggested by BCS:

• Move your changed files into some temporary location, stripping out any .svn directories
• Update your working copy into a clean working state
• Copy your changes back to where you want them to be
• Commit the resulting working copy