Defining boundaries in terms of repositories

Question

I'll set the scene first...

We use Subversion and currently have a reasonably large Main repository. I'm looking to break it down though, with the possibility of moving to Git at a later date. The reason being is that a) Git can't do subfolder checkouts so favours smaller repo's, b) we can use branching a lot more (branch per feature).

We have a web application, and also a web automation application.

They don't directly depend upon each other in terms of code. But the automation app depends upon the web app in terms of design. If a change is made in the web app it could break the automation app.

I'd like to split them into separate repo's, but a good point was raised. It's handy to have them under the same repo, so you know that at a certain revision they both worked together.

Figuring that out with two separate repo's, with two sets of revision numbers is obviously quite tricky. The other problem is we have a number of apps (not just the automation one that depend on each other, API's etc...).

Just wanted to see people's thoughts. If you've dealt with such an issue? Do you think they should or shouldn't be split etc... Do you use some sort of deployment tool to track the various revisions of each repo working together etc...

Answer 1

first, you create a clone of your svn repository, you can then split the resulting git repository with git filter-branch.

to get the two projects dependant again, use submodules. this way one repository can be used with a fixed revision (useful for libraries, in your case the web app)

Answer 2

In terms of tools, if you build using Hudson, it keeps track of the set of repositories and revision numbers used in each build for you. You can tag from this if necessary.

If you've got a tool that works this way then it's not so important to limit the number of revision numbers you're tracking. I split it like this - 1 number can be tracked manually, >1 needs tool support. But they don't need to be complex tools.

I prefer a single repository, but that's just a personal preference. It's based on a revision number being unambiguous, with multiple repos you need the repo and the number. Repo boundaries are then on policy changes (eg, this one is used for code, this one for company docs, this one for deployment, etc).

Git just doesn't work that way, so you don't have the option of using a single repo. That's not a bad thing, and most systems (like Hudson, Redmine) will happily support this.

Answer 3

Splitting them allows them to release independently, with their own version numbers, but as you note, keeping track of the dependencies can be tricky. We moved from an Ant-based build to maven to help us with our dependencies and despite some teething troubles it's been worth it overall. (We have multiple apps that depend on each others' apis in strange and wonderful ways.) The basic schema we follow is to use the Apache Portable Runtime's version numbering, which is a three-digit system where the versions use a standard MAJOR.MINOR.PATCH convention.

As far as the process for splitting them goes, I'd recommend splitting them first in Subversion; then if/when you move to git, you can simply point git svn at the relevant parts of the repository for the conversion.