1

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?

Bkwdesign
  • 101
  • 1
  • 6
  • Thanks everyone for your helpful feedback. This is what I feared would be the answer. Makes sense, though. – Bkwdesign Jun 01 '09 at 12:32
  • FWIW - In regard to 'being more careful in the future' I've really enjoyed using AnkhSVN within my Visual Studio 2010. It's done an excellent job of helping me perform perfect commits – Bkwdesign Jun 03 '11 at 16:22

5 Answers5

4

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
  • 10,141
  • 3
  • 34
  • 46
3

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
  • 4,157
  • 1
  • 18
  • 15
1

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
  • 43,293
  • 10
  • 75
  • 117
0

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
  • 5,084
  • 1
  • 23
  • 28
0

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
  • 6,132
  • 2
  • 25
  • 15