Branching multiple projects in subversion

Question

We have a single application with 20+ eclipse projects in a single repo. So far we haven't branched much, but we are going to try using branching features a little more.

Each feature typically touches a sub-set of the projects--it might hit all the java projects, or all the flex front-end projects, or just one or two of them.

So being somewhat inexperienced at branching I'm wondering if it's a good idea to create the feature branch from just the projects that change or if it would be a better practice to create every feature branch with all the projects every time--what might be the pros and cons of each approach (I'm mostly worried about potential problems with the "partial" solution, like what if I need to pull another project into an existing branch)?

Answer 1

I would recommend avoiding branching a subset of a repository. If you find yourself really wanting to do that, it may be worth pondering if you really need to split things out into multiple repositories.

The branches themselves are made with cheap-copies, you consume no space on the server for each branch.

It's going to be confusing to manage which projects exist on which branch, as you noted it will also may be a hurdle for some of your team to have to figure out which revision of a missing project to copy in to 'branch' it. I'm pretty sure members of most teams I've worked on would just grab the latest - this may be desired, but conceptually that seems even more confusing to me.

It may also be a hurdle to see a diff between two branches - there will be a lot of forest, making it difficult to pick out the trees you actually wish to see.

It's definitively the community norm to branch the entire repo. I'm sure you could make it go - but your successors may curse you.