How to undo subversion misuse?

Question

I am being asked to troubleshoot an issue caused by incorrect use of subversion (as far as I can tell).

Here's the history, which has been marred by some time passing, user confusion, etc. but is the best I can figure out. The intended goal was to archive the file set at a given point in time (essentially to tag the repository but the user did not know this).

• user has a working directory checked out
• instead of creating a tag, the user copied files via unix copy commands (not SVN move or SVN copy) to a sub folder within their working copy.
  • Eg The working copy is /var/tmp/working, they copied files into var/tmp/working/todays_date
• the user noticed that some .svn directories were missing from this new directory, so they copied .svn folders from another directory (they're not sure where) into the directory with their "tag".

Is this the best way to fix it?

Thinking I'd try the following:

• recursively delete all .svn folders in their mistaken sub-directory
• copy the directory out of the repo locally
• check out a working directory before their last commit
• overwrite the new working directory's files with the "exported" files
• go through the normal update/commit process
• create a tag

Does this make sense or am I opening myself up to other issues?

Other Questions

• what is the best way it educate this user so they won't do it again?

Update: More information

Got the following from the user:

• I did the work, then attempted to do a svn add.
• I then did the svn commit which gave me some errors.
• At that point I moved the .svn files then it finally did the svn add and commit without errors
• However svn log does not show the log message for commit.

So it looks like the user copied .svn folders in an attempt to make a commit work, and then it apparently did add and commit, except we're not sure if it did because we can't find it in the log.

Answer 1

You should just update the root svn folder. It will retore the deleted (moved) files, the other one that were not indexed will not be touched.

Then you can use the svn delete command to clean, or svn move or svn copy. But if you do that you will lose the ew "not yet indexed files" and the changes. So perhaps, the svn delete is easyer (but you will lose the history, because svn will have no way to know that the new file is a move from another one)

Answer 2

You have to solve 2 tasks, as I see

• Undo bad commit(s) around subdir in trunk
• Restore user's WC

yes?

1. Undo commits by NEW commit with reverse-merge of wrong commits
2. Update working copy of user to this commit

Answer 3

So, after conferring with the group, we were able to do the following to fix the issue:

• Backed up the folder
• Created a clean copy of the folder structure without the .svn folders using rsync:

rsync -avr --exclude='.svn*' /originaldirectory /cleandirectory

• updated the working copy
  
  • confirmed beforehand that this user's changes were the only ones that mattered in this part of the structure
• resolved conflicts preferring the user's local working copy files.
• attempted to commit to find the incorrect directory structures
• deleted those trees from the file structure and re-updated the repository to pull them down again
• For good measure, overwrote all the file contents with the clean files to make sure they were up to date
• did a forced add of all files in the structure.
• committed.
• created a tag when finished.

Needless to say, we'll be going over Subversion best practices with them soon. Thank you for the pointers, all!