[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.