Comments on: Directory Assistance

Question: Directory Assistance

mkb — Wed, 10 Sep 2008 12:51:05 -0800

What pitfalls should I look out for when reorganizing a source control repository?

My current job involves being the standard bearer of sorts for good software development practices. As such, I want to get our totally messy Subversion repository reorganized so it can be understood by mere mortals. Complicating matters is the fact that within our group there is a totally separate CVS repository. I would like the code from both of these systems to live in the same place. Fortunately there aren't different branches of the same project across the two systems, as far as I can tell.

Most of the projects in these repositories are self-sufficient, which makes for a lot of duplication, but I think will make the reorg easier at first.

By: rhizome

rhizome — Wed, 10 Sep 2008 13:34:10 -0800

1) Document what you have, where it maps to the projects, etc. Give people a reference for when they are lost.

2) Get rid of CVS and move it to SVN. People will undoubtedly tell you to move to git or Perforce or whatever, but you shouldn't make any wholesale moves yet.

3) Start re-organizing SVN. You don't say what's messy about it, so I figure you know what you'd want to do here.

By: bottlebrushtree

bottlebrushtree — Wed, 10 Sep 2008 14:02:30 -0800

Move as much third party materials into its old directory to keep it separate from your code.
Put unshipping tools in a build or tools directory.
These two things will help you keep licensing issues mostly under control.

By: mkb

mkb — Wed, 10 Sep 2008 14:08:22 -0800

What's messy about it is that with the two repositories combined, there are about 200 top-level projects.

I should have mentioned that is certain that CVS will go away.

By: Leon

Leon — Wed, 10 Sep 2008 14:12:01 -0800

It looks to me like you have two problems - refactoring code to extract common components, and moving to a sane SVN/project layout. How you do that... well, it might make sense to start with the low-hanging fruit.

Lowest hanging fruit are brand-new projects. They go in the new repo. Simple.

Next come the 3rd party components that have made their way into your current repos. Extract them into their own playpens, use svn:externals to pull them back in.

Next, I'd say, are your own common libraries, which will probably take some extracting, as they get tweaked as they move from project to project.

Then the projects themselves. I'd probably set the current repos to read-only, for historical purposes only (unless there's a bugfix on an old branch, but cross that bridge when you come to it), and move things to your new layout one-by-one.

This is just how I'd do it, of course. I might be completely wrong.