[JesseAldridge]

> they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits

lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.

[eterm]

It may well be the reason. I don't know the parent commenter but speaking from my own experience I recently tried to migrate a legacy code base from svn to git and the common tools all failed for me. One of them ran for ~72 hours before falling over for "reasons".

That was only ~6 years of commit history too. I could imagine 30 years is a whole extra logistical challenge. Not to mention making sure the whole developer base is aware of the change, prepared for it and willing to either update documentation where it refers to revision numbers or write some instructions on how to find a new commit reference from an old revision number.

The tag model is also different between svn and git.

It's not out of ignorance that the switch can be difficult, we've had some projects on git for years and we're comfortable with it.

Just because you've switched easily from svn to git doesn't mean everyone has the same experience.

[thewebcount]

Same. We have a 20 year old code base we migrated from Perforce to svn about 10 years ago. Now they want to migrate to git. Unfortunately, we can't get it to work either. Same thing - after many hours of running it just fails with typical useless git messages that nobody comprehends. It's quite frustrating.

(And personally, I hate git. I've used it professionally, and while it works, it's very difficult to use compared to svn or p4. Between it's utterly incomprehensible made-up terminology and horrid syntax, and hashes for commit numbers instead of just an incrementing integer, it's quite a bit less useful than svn was for us. But it's being forced on us, unfortunately.)

[goatlover]

Maybe the old guys didn't think there was a good reason to switch from SVN to git, if SVN had been working for them. It sounds like switching just because git became more popular.

Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.

[simias]

I used to be one of the "old guys" fighting against git because subversion is "good enough" and I didn't want to relearn a new tool. I finally had to learn git because a project I contributed to made the migration and I could no longer postpone it. I'd never, ever, go back.

At this point I'd go as far as saying that git is objectively superior to SVN because it does everything SVN can and then more. One caveat being potentially very large repositories and especially repositories containing sub-repositories, git was terrible at that and while it's improved over the past decade it's still a bit messy. Unfortunately in my experience these types of repositories are fairly common in proprietary codebase where people often don't hesitate to commit big binary files alongside the source code.

Still, I'd say that as a rule of thumb if a codebase is still in active use it's probably worth taking a week or so to migrate it to Git unless there's a very good reason not to.

[ScottBurson]

SVN has its limitations, but having used Perforce in my last job and now using Git, I wouldn't mind going back. It's a judgment call, as the two systems have different strengths and weaknesses, but I don't find Git to be an overwhelming improvement. For instance, in Git, if you merge from branch A to branch B while work is underway on both, then merge A to master — and assuming you're using squash merges, as is pretty much essential to get a readable commit history — and then merge from master to B, you're in merge hell, because Git doesn't remember that the squash-merge commit contains some of the changes that were already merged to B. Perforce gets this right: it gives you an equally clear master history, with a single merge commit each time you merge from a branch, but doesn't lose the relationship of that to the individual commits in the branch.

[oaiey]

Write down the nicknames. In 15 years git is ripe for next gen source control and then the same ppl will complain who are now advocating what is so hard on migrating

[u801e]

> But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.

I went through periods where I had to use CVS, then SVN, and then git. The transition period between each one was a little problematic since I had to constantly refer to the documentation in order to learn the new source control commands, but, in my opinion, one should be capable of learning new technologies.

[hannofcart]

SVN? What's that? All you young whippersnappers keep harping on the new and shiny.

Real men use cvs.

(I kid.)