[hrktb]

If a team with extensive experience in CVS is already dragging it's feets to move to SVN, trying to get it to git is a fool's errand.

And SVN isn't the plague either, if they could be happy with, it should be good enough for a number of years. At least the migration path from CVS seems a lot more realistic.

Moving legacy systems is always a pain, and more often than not it's a matter of having enough people fluent in the target technology. I guess the point of the rant here is to urge people to get new hammers when their current one is getting old.

[coldcode]

10 years ago I managed to convince my employer at a time to move to Subversion from some proprietary system. Labelling a version of their customer facing application took all day as it copied every single file. We moved the code into Subversion as a test and showed we could label it in 1 second. Sometimes you have to show people to get them to understand.

[hrktb]

I think convincing people is usually the easy part. More often than not they'll have shopped around and choose the solution themself. Or they hit a wall with the previous solution and need a new one no matter what.

I remember the tedious part being actually moving all the projects, all the teams over. Change the procedures. Change the tools, be it on the dev machines, CI, managers etc.

Then you remake all the weird scripts that were used to take stats, the commit hooks, or the stuff people didn't even remember existed but is still critical 0.01% of the time.

Usually it won't be done in one scoop, more like building the basic viable architecture and moving one project after the other, keep both stuff working in parallel with some people who'll trail behind and keep some translation layer between the legacy and the new system until everyone around has moved and they feel the peer pressure.

I've seen a lot of these transitions in mid size (70~200 people) corps, it would easily take 2 to 6 months to complete, even with goodwill on most fronts. Not the best memories.