Can an old exported set of files be compared to a subversion repository?

Question

Here is the problem: We have all of our development under subversion, but our beta versions are just mish-mashed bits of exported files that were not all put there at the same time. Or, to put it another way, we make our changes to versioned files, and then when we think we are happy, we manually export them by simply copying them to a different directory.

Well, we would like to have the whole works managed by Subversion, with the beta version as a simple working copy of the head of the trunk. I know that I can start with the trunk head, and simply roll back specific areas until I reach the same files, but it would be nice to know what revision each file needs to get rolled back to.

Does such a tool, that will take a set of files/directories and compare it to a repository, giving revision numbers for each file/directory, exist? If not, how would I go about putting a script together to do this?

Answer 1

Ah, yes! "Frankenversions"!

This is where I would recommend a build management system like CruiseControl or Hudson. These systems will create a tag (copy) of every build they do, so you can be assured that everything that corresponds to one of your builds is versioned consistently.

I like to add code to my build scripts to even take the build number from CruiseControl and put them into my builds (like my "about" files, my assembly metadata, etc). This will make it easy for you to cross-reference your actual working software with what's in svn.

Answer 2

I sympathize with your problem, but this is a problem you're going to have to solve in a different manner for the future.

Subversion has a notion of "copies of a directory" which are lightweight and doesn't occupy much space in the repository at all.

Typically, if you use the often used layout of tags/branches/trunk, then you would make a copy of your trunk into a new sub-folder of your tags directory when you release something.

That way you wouldn't have to try to figure out what version each file was after the fact, Subversion would track it for you.

This is pretty much like saying "I know I drove my car into a rock wall, but could you please help me put the car back together?". The answer is of course to avoid driving into the rock wall to begin with.

As far as I know, there is no function in Subversion that will tell you which version of each file that your on-disk files look like, so either you make some scripts that tests version-by-version for each file, or you do it manually.

Oh, and yes, avoid driving into that rock wall in the future.

Answer 3

You could try writing a tool to do this using SharpSvn. The challenge you have though is to figure out what repository url corresponds to your file. After that you can just fetch the log, and for each revision of that file's log call diff to verify if it is different or not.

Again, I think the biggest problem you have to solve is finding the Subversion URLs for each file

Answer 4

I would like to expand on Sander's answer above and follow through to the end.

Create a tool using the SharpSvn libraries that follow the following algorithm.

FOR EACH of the exported files
  ITERATE backwards through the revisions of that file
  IF the revisioned file matches your exported copy
    SVN COPY that revisioned file to another branch

Once you've done that for all your files, your new branch should have working copies of your exported versions. It's messy but it should get you where you need to be.

Answer 5

forget SharpSVN, there are perl and python bindings that work as well, or you could just use the svn command line in bash. You said script after all.

If using the command line, you'll want to search the directory tree for the equivalent file, then use the svn log command to get a list of revision numbers for an individual file; you'll also want the svn diff command (using the -r option) to compare your file with the revision in the repo.

I'd print out all matching paths and revision numbers and manually tidy it up (just in case you have duplicates!), but you'd want the svn cp command to make the branch of the controlled file to a new directory.