views:

135

answers:

5

So I've been happily using subversion to regularly commit files in my stack of projects related to my massive Visual Studio solution.

I decide to do a svn export one day, and, decided I needed to see how my project was working back in October of 2008. So, I export to my local file system, revision 37.

When I go to compile the project, somehow there were 2 or 3 files that got overlooked way back in October. Let's say they didn't get committed until revsion 99, or better yet, they're still not committed at all.

Is there a way to tweak the commit number on a file, so that it gets matched up with the correct revision that you meant for it to have been? Thus, if I re-export revision 37, I'll get a correct and working solution in Visual Studio?

A: 

It looks like something that shouldn't be possible.

You could try take the two files from a later revision and use these instead (with the files from revision 37).

Peter Stuifzand
+4  A: 

Not really. Subversion revision numbers apply to the entire tree of source code. If you were able to make changes to a commited revision, that would destroy the idea of change management.

What you can do is create a branch off of revision 37, and make changes to that. This will create a new revision, say 100. You can commit that then, and you will have your modified revision 37 that you are looking for.

Matt Brunell
+1  A: 

No, that's not possible. You can't change history.

If it was possible to do what you ask, then that would break the whole concept of version control: having a reliable history of your commits.

Stefan
+2  A: 

It's possible, but requires you to not be a faint of heart, know the SVN repository dump format and have a steady hand (and backups).

The process would be to dump the whole repository in the text version, find the entry for the revision you are looking for and add the information, then reload the dump (overwriting the existing repository).

Unfortunately, the format is not for the faint of heart (it's similar to HTTP with extensions, with most fields being preceded by their length), and breaking it is fairly easy.

It's also not really recommended; just commit the files now and be more careful in the future.

ASk
A: 

It sounds like you don't really care that it was revision 37. Rather, you are trying to re-export a revision with a particular real-world property (i.e. rev 37 happened to be the one you gave your client).

As Matt said, you really want to create a branch from rev 37. Essentially, that means you're going to copy rev 37 to a Subversion directory with a name that explains what it is, such as /branches/client-A. Then, add the missing files to the branch and commit. Then, you can export from /branches/client-A to get what you want.

runako