Moving back SVN Data after hard disk failed

Question

So long story short, my hard disk on my main machine was failing. I couldn't check in my work as a release build was imminent, so I slung my six projects I was working on to a file share.

New disk arrived, new copy of windows, et al.

Now I have my project data with my changes copied back to my C:\Projects directory with Tortoise SVN installed and Visual SVN on Visual Studio 2015.

How do I hook back up my working copies to synchronise with the server? I have checked out the projects again without my changes, however just copying the project folders on top causes issues. Luckily I had zipped up what I had checked out.

To make it clear, I currently have: - Tortoise / Visual SVN installed - Working copies checked out of the repository to C:\Projects - A file share with what SHOULD be the working copies ready to go

I want to essentially replace whatever is in C:\Projects with the working copies from the file share.

nb: Before anyone starts, I am aware that this is really poor practice but without going into a lot of detail this was how it had to be done.

Answer 1

1. Do a checkout of whatever revision you were working with your BASE at that time.

2. Simply copy the modified (and saved to the share) files over those in the working copy of the checkout.

3. Do an svn update (whatever stands for that in Tortoise) to sync your working copy with the recent developments done upstream.

   Note that this might lead to conflicts which you'll need to resolve and mark as such.

4. Commit.

Alternatively, the main step (svn up) might be done another way:

1. Create a remote branch off your base revision, say

   svn copy ^/branches/trunk@BASE ^/branches/mywork
   

2. Update your working copy to that branch:

   svn switch ^/branches/mywork
   

3. Copy the modified and saved files over to the working copy replacing whatever is there.

4. Commit — updating that "mywork" branch.

5. Switch back to "trunk" and merge your work:

   svn checkout ^/branches/trunk
   svn merge ^/branches/mywork
   

   This might result in conflicts, as usual.

The difference in these two approaches is that the first attempts to make things look like you've just implemented the new stuff (atop what's in there upstream) and the second one pretends you were hacking away on a separate branch and then do an integration merge.

(Note that in my examples I assumed you were working on the trunk; if that wasn't the case, adjust the examples accordingly.)