1

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.
    • E.g. 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.

SeanKilleen
  • 8,809
  • 17
  • 80
  • 133

3 Answers3

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)

dzada
  • 5,344
  • 5
  • 29
  • 37
  • I thought about that, but there are concerns that the trunk has progressed since that revision. I'm thinking that I need to maybe copy the whole directory (just in case of disaster) and then update to the last revision of the working copy that I can tell (svn log appears to be strange as well). I'm just nervous because since I don't know the history of the user's commands I can't trust the setup at all. – SeanKilleen Nov 13 '12 at 23:06
  • If all your changes are just new not indexed files then do a revert these files will stay untouched – dzada Nov 13 '12 at 23:08
  • Hi, please see the update -- added more information from the user. Not sure how to tell what's been committed and hasn't yet. – SeanKilleen Nov 14 '12 at 13:42
  • Aie this is so wrong ^^. First lets copy for backup all files touched by the user, then delete the folder in which was the .svn then update. It should rebuild the SVN tree as it should be. Then let the user remake his changes. And then commit. (Why the first commit did not work is weird, perhaps he needed to clean and update the folder before to commit) – dzada Nov 14 '12 at 19:29
0

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
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • Hi, thanks for responding! Please see the update -- I added more information from the user. Could you explain or link to the reverse-merge concept? Could be the ticket but I'm not sure, especially if other commits have been made to the repo in the time he's been having this issue. – SeanKilleen Nov 14 '12 at 13:43
  • 1
    @SeanKilleen - see [this discussion](http://stackoverflow.com/questions/13330011/how-to-revert-a-svn-commit) – Lazy Badger Nov 14 '12 at 14:00
  • 1
    @SeanKilleen - also [Undoing Changes](http://svnbook.red-bean.com/en/1.0/ch04s04.html#svn-ch-4-sect-4.2) from old SVN Book (disappeared in later versions of book) – Lazy Badger Nov 14 '12 at 14:12
0

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!

SeanKilleen
  • 8,809
  • 17
  • 80
  • 133