Do you have centralized or distributed SW development? On my project we only have centralized development. I didn't see the advantage to move to a distributed approach and was happy to make to step from CVS to SVN (for us already a big step!). SVN works fine for us. We have many tools and Subversion is well supported in terms of plugins for integration (Jira, Hudson etc.) Could you think of reasons to use a distributed approach while having only centralized SW development? I could be wrong but it sounds like adding complexity for something I don't really need. I could be completely wrong though;)

Cheers

Harry

Could you think of reasons to use a distributed approach while having only centralized SW development?

I would hate to give up cheap and easy local branching. (I've used both Mercurial and git but prefer git. Either one allows this.)

I don't think I understand the concept of "centralized development" except perhaps if there is a single developer. In our case we have 20 developers working on different aspects of maybe 10 different but related projects at any time out of a pool of around 40 projects, all of which share code. Using a distributed revision control system means that we can easily maintain central dev and stable versions of each repo. Developers use a local clone of the repos they are working on (we use Mercurial's sub-repo management facilities a lot!) and run it as a local sandbox repo, syncing from the central repos and workmates repos as they need.

It sounds like anarchy, but works very well. It also works very well with our nightly builds which build all projects against the central repos. For dev builds the nightly build can be against the tip version of each of the sub-repos involved. We may have almost any number of our developers working on a specific project at a time and we may have several developers updating the same file in the context of different projects at the same time - mostly it just works.

Doing this with a single central repo would be a nightmare! We were doing it with CVS and merges between branches were terrible with many manual checks and balances and much gnashing of teeth. SVN may have been a little better, but no where near as good as using a distributed system.

If you have the chance try moving one of your projects from SVN to Mercurial or Git. Mercurial (at least, don't know about Git) can even use an existing SVN repo, but I'm not sure what the down side may be doing that.

There is some pain moving from CVS and to a lesser extent from SVN in figuring out how to break up an existing repo. Mercurial at least doesn't allow you to cherry pick parts of a repo to generate a checkout that is a sub-set of the total repo. Using sub-repos fixes that to a large extent, but you are likely to end up moving stuff around between repos if you don't think hard about the structure up front.

True laziness is hard work

Git has git-cvsimport and a two-way SVN bridge (git-svn), so you can locally switch to git without the powers that be never noticing. But I am unaware of an easy way to cut up an (imported) Git tree into nice submodules.