Our team has been using SVN for managing an application of decent size and over time a rather complex hierarchy of branches and tags has built up, which is following the basic standard layout for SVN repositories, but is more nested:
|-trunk
|-branches
| |-releases
| | |-releaseA
| | `-releaseB
| `-features
| |-featureX
| `-featureY
|-tags
|-releaseA
| |-beta
| `-RTP
`-releaseB
|-beta
`-RTP
(The feature branches are obviously temporary branches but we have to take them into consideration as it won't be feasible to close all of them at once in the near future)
For several reasons but primarily because merges have been becoming an increasing pain, we are considering to switch to Mercurial.
The main problem we are currently facing is migrating the existing code base without losing our history. I've tried several migration tools (e.g., yasvn2hg, hg convert and svn2hg) with yasvn2hg being the most promising, but none of them seem to be able to deal with nested hierarchies but they all assume that branches and tags are organized in one flat directory respectively.
The choice between named branches or clones as the conversion target of old SVN branches is not a limiting factor in this case, as either solution would be appreciated. We are currently experimenting with both options and how they would fit into our current processes but haven't decided on one yet. I'd obviously be interested in recommendations or experiences with similar setups concerning that issue as well.
So, what is the best way to convert a nested SVN branch hierarchy like this to Mercurial?
Converting one branch at a time into a separate repository would be quite annoying and I am not sure if that would be the right approach in the first place, depending on how the tools handle historic merges and need to be aware of all other branches?