Question

I’m maintaining a project that was not initially using a version control system. Instead, there would be periodic snapshots of the code base saved into a backup folder, and there would occasionally be a makeshift branch created. When I got a hold of the project, I created a Subversion repository for it, committed each snapshot to the repository (using WinMerge to update the working copy each time) and made branches to correspond with the “expensive” copy branches in this backup folder system.

Now that the project has been in Subversion for a while, and development has been done in real time in the trunk, I’ve been given a few older branch snapshot folders that were pulled from a developer’s machine. I found the right spot in the trunk’s history to retroactively branch from… however, my question now is this: If I create this branch, is there anything useful I can do with it? Can I retroactively merge this branch into trunk’s history, so there’s extra file history available for a file from the branch?

Essentially, I would like to take this old “expensive copy” branch, create a branch from the appropriate spot in trunk’s history, copy the old branch over, commit each old backup copy to the Subversion branch, and then merge everything back in at the appropriate spot, as can be seen in the following crude ASCII-art diagram:

     trunk: ... r107 -> r108 -\-> r109 -> r110 -> .... -> r137 -> .... -> r394
old branch:                    -> r395 -> r396 -> r397 -/ (r398)

The current repository’s revision is r394. Creating the branch would be r395. Committing a couple “expensive” copies would be r396 and r397. Merging back into trunk “before” the point in time represented by r137 would bring the repository to r398. Now, viewing the history of a file anywhere from r137 on would also include the changes committed in r396 + r397 and subsequently merged in r398.

Is something like this possible without re-committing r137, then doing the merge, then re-committing r394 again (which I don’t think would give me what I want, anyway)?

Answer 1

Subversion allows you to create a branch from an old snapshot, so you can branch off from r108 and commit your changes (r395-397) into that branch. However, you can’t go back in and “insert” a commit into the tree’s history. If you have administrator access to the server, you may be able to do some kind of kung fu with svnadmin dump to insert these changes into the tree at the appropriate time in the history, but it would throw off all of your revision numbers following that point (not to mention it would be a rather complicated procedure to go through). I can’t imagine that process not causing all sorts of unexpected problems, especially with merge tracking.

I tried to do something similar a while back, and I found that porting history from a non-organized system into a version control system was usually more trouble than it was worth. Instead, I took a code snapshot and made a clean break; everything before that snapshot was still available on the old server using the old system, and from that point onward all development would be done in the Subversion repository. We didn’t lose any information and all of the history was still there, but it required developers to access the old server to get to it. It was annoying at first, but after a couple of months, the Subversion repo had developed enough of a history of its own that the builds from the old system became generally unused and were migrated out to an archive server. Since you’ve already set up your Subversion repo and included historical builds it’s probably too late to make a clean split between legacy code and current code, but the idea still holds. You can add this new historical data to a server/fileshare that is hosting your historical builds and if anyone wants to see the most detailed history of a file beyond revision 200 (or whatever the rev number was when you stopped committing old builds and started doing active development), they can check the server.