What are the long-term effects of reorganising a subversion repository

Question

The subversion repository at work was set up without much planning as to its structure. There are currently no explicit tags, trunk or branches configured, although some tagging metadata is present through the use of subclipse:tags

Currently the repository is in the format:

/CoreCodeA

/CoreCodeB

/Project1

/Project2

Recently a new developer started on "version 2" of our internal application which he placed under different folder:

/new/NewCoreA

/new/NewCoreB

/new/Project3

/new/Project4

These projects all have dependencies upon various parts of the Core code, and upon similar projects (e.g several projects might be dependent upon the same theme). These dependencies are referenced inside the contents of some text based project property files.

I've been playing with using the svndumpfilter command, piping the output through sed and reorganising this into two separate repositories ("old" and "new"). Easy enough to do, and I now have two distinct repositories with trunk, tags and branches set up (the subclipse tagging information can be reparsed at a later date).

My concern is that by fiddling with the subversion structure over every commit, that I am breaking builds that previously worked, especially given the dependencies upon other projects. On the other hand, I need to have tags and branches in this codebase sooner rather than later. But I also don't want to have to force the developers to re-check out their projects if I change my mind a few months down the line.

I guess my choices for each repository are:

1. Mark the repository with a "pre-restructuring" tag, reorganise the repository how I want, tag with "post-restructuring.
   • Good: Won't break historic builds
   • Bad: Effectively disconnects future work from past work, no easy ability to make x.x.1 patch releases
2. Restructure the entire repository, breaking previous builds
   • Good: History continuity of code is maintained
   • Bad: Previous builds are broken, will definitely require x.x.1 patch releases if ever needed again
3. Restructure the entire repository AND edit the project property files at each stage
   • Good: Continuity of code is maintained and projects should build
   • Bad: Editing actual content of files is far more fragile than simply changing metadata concerning their location

The first two choices are easy enough to do - but I'd like some real world 20-20 hindsight from other developers about what they did in a similar situation, and what went wrong or right.

Answer 1

I don't think you need to worry abut breaking older builds: SVN stores entire ource tree per revision and if you try to get an older version it would have the old directory structure.

The big issue is that moving files around in done by deleting the file in the old location and creating a new file in the new location. this means that if you move a file you cannot see it's history - because it's a different file now.

Answer 2

I wouldn't touch the history. It was bad back then and you'll have to pay the price if you ever want to go back there again.

Of course, you might "know" that you'll revisit the past often, then it might make sense to got with #3 and put the whole repo through it's paces with new .1 releases of all important points.

Answer 3

Repository layout (change) is more about your development organization than anything technical. Without knowing what's the amount of code, number of needed changes in code after restructuring and number of people working on the code, it is quite difficult to recommend anything specific, but I'd start with getting all the affected people on board with this and dedicating 1-2 days to the repo overhaul - code freeze, only fixes to make code buildable are allowed. In the end, everybody will be a lot happier. Trying to do this undercover will possibly leave you with a rogue developer still doing his/her own branches in some dark corner of your SVN server.

And I would not worry that much about access to the historical code layout. You can always tag the current layout under something like /oldlayoutdonottouchthiswithoutrealneed and leave it there for patching the old versions. For tricks like this, SVN is a really great tool.

P.S. I have never used subclipse, but looks like subclipse tags are quite different from by-the-book SVN tags. They seem to be more liks CVS tags. Make sure you do not have confusion there.

Answer 4

Is there any way you can get the build property files to reflect relative paths rather than hardcoded paths?

Assuming that your task involves organising the main folders into tags, branches and trunk , I'd think the subfolders/files (atleast to an extent) will retain their relative location(s)?

If I were you, I would consider fixing my properties files to become more generic and independent of absolute paths..

Hope this helps.. Cheers!