How to revert back to an uncommited version in svn

Question 1

Sorry, not much you can do when you revert your changes. You basically told Subversion to trash everything. By the way, unlike what others have mentioned, using a distributed version control system won't help. If someone updated a file in the remote repository that you've worked on, you can't push your changes to the remote repository without first pulling in their changes. (You can create a branch and push your changes, but you could do the same with Subversion anyway.)

It's the curse of working with a team of people and something that version control systems have been struggling with for years. Basically, if you and someone else change the same file, you want to make sure you incorporate the other person's changes into your version before you check it in. Otherwise, their changes will be lost.

Normally Subversion will do the update without a problem (although you should test to make sure your changes will work with the updated versions of the file). So, what should you do if you get a conflict during an update?

Panic thee not! Look at the conflict message and see what it says. Many times, it's something like an incoming update to a file that you deleted, or a delete to a file you updated. These are usually not too much of an issue, and you can use svn resolved to mark the situation as resolved. Sometime, it's a line conflict in a single file. Take a look at the conflict. Subversion marks them with >>>>>> and <<<<<<<. The vast majority of the time, it's something that's easy to fix. You added foo = bar and they added snafu = bloop, and you really need both lines. Sometimes, it's a line spacing conflict. They reindented the file, and there's really no conflict. Just because a conflict is reported doesn't mean there really is one.

In the worst case scenario, just checkout a new working copy and use that. However, if you do that, do blindly copy your changed files over the new working copy because you'll destroy the other person's changes.

You can always create a branch and commit your code to that branch, and work out your issues later. That's one of the good reasons to branch.

Whatever you do, don't revert and lose all that work.

One last chance...

Do you use a Mac with Time Machine? I understand new versions of Windows also version files too. You might be able to use the versioned backup to get back your changes.

If nothing else...

Look at it as an opportunity. When I was a programmer, things would happen all the time where I would lose massive amounts of work, and I had to start from scratch. What usually happened is that I wrote better code the second time through. I was more familiar with the issue. I knew the traps that were causing me so much grief.

Sometimes, when I was programming, I could take one of two paths. After a few days, I realize that the path I chose was the wrong one, and I kept pushing down because I've already spent so much time on the project. As I handled the problems, the code got uglier and nastier. I would curse myself for making the wrong decision, but I would have to live with it.

Losing everything allowed me to do things differently. You've solved the problem once, you know what worked and what went wrong. You spent four days of work, but you can probably redo much of your work in a day, and this time, do it right.

Question 2

No, if you had local changes that were never committed and you reverted the files back than those changes are unfortunately lost.

I wanted to add this as a comment but it was getting too long..

The best practice to avoid having something like this happen in the future is to make it a habit to commit often, several times a day. If the changes you are making have larger scope and cause the build to fail create a branch and commit your work progress there until it is ready to me merged back to trunk. But don't work for extended periods of time without committing your code. Accidents can happen and loosing a few days worth of work can be insanely frustrating!