So why do companies keep switching from SVN to Git and not the other way round?
Three reasons: most open source projects are on github, the herd effect and because it's not that complicated in the day to day. The most complicated thing about Git is rebasing but even that is not rocket science, you just need to read a decent tutorial about it and keep practicing (the fact that it should be infinitely simpler is a given)
I don't think I know more than half of what git is capable of and I'm able to work with it every day.
Git's UI admittedly isn't great but you can use a few aliases to make your life better.
Let's face it. Most professional developers, including myself, are not really interested in version control. Of course they are aware that it is neccessary but they want to interact with it as little as possible and focus on their actual work instead. It is something that should more or less happen in the background. And of course as an employer you don't want the precious time of your developers to be spent on non productive stuff.
Totally disagree :-D Getting source control right (be it subversion or git or whatever) is very important. Even the fact that you can go back in time is something you should know how to do and can be valuable to your or your employer.
Subversion is much better these days then when Git came around but there's value in the "distributed" part of source control. Maybe Git isn't the best one (Mercurial is cool, bazaar is another contender) but as often happens with competing technologies, one gets more popular than the others, not always because of "absolute merits".
When comparing SVN with Git, it is pretty safe to say that the latter is much more complex. More things can go wrong. And they will go wrong and cost money.
I don't think this is a fair argument, not enough to dismiss Git though. If we apply it to every technology, innovation wouldn't ever happen. We are software developers, we can't dismiss a technology because is more complicated. Though I don't like complexity for complexity's sake, "being more complex" than Subversion despite being a fundamentally different tool isn't ground for automatic dismissal. Maybe there are companies that could just as well use subversion as they use git, but most likely they are developers who already know how to manage and maintain a git based source tree, hence that's what they end up doing
In SVN there is your local data and a central repository. That's easy to understand and there is a single source of truth. In Git, there are multiple repositories.
"Convention over configuration", you just decide that one of the repos is the central one.
In SVN, commits have simple consecutive numbers while in Git there are 40 digit hashes.
We could make the same exact argument for auto incrementing numeric IDs and UUIDs, but honestly... didn't we solve this a thousand year ago? It's not like I'm going around memorizing which commit has which ID. We use the message of the commmit and its timestamp because we're humans and not machines.
You could add more item to this list, for example the cryptic command line interface of Git or the possibility to modify history.
This I agree with :D It's truly bad. Mercurial's UI made more sense to me
Thanks for the detailed answer. You have made some very good points.
Getting source control right (be it subversion or git or whatever) is very important.
I have no doubt that it is important but as a developer I don't want to spend more time and effort on it than absolutely neccessary. It is more of an infrastructure thing. It is also important that someone keeps the servers running and that someone cleans the toilets at the office. Most developers are probably more interested learning a new programming language, framework or some other development technique than learning another VCS.
Subversion is much better these days then when Git came around but there's value in the "distributed" part of source control.
This value of being distributed is something I don't really understand. It sure makes sense in the open source world. But in professional software development with teams of 2 to 20 developers working closely together, it is important to make your code available for other team members as soon as possible instead of keeping it in your local repository. I know you can work with Git in a centralized way but in this case you don't really need a distributed VCS. Being able to work offline is no big deal anymore and will probably be even less important in the future.
Most developers are probably more interested learning a new programming language, framework or some other development technique than learning another VCS
Sure, and I understand your earlier point about "infrastructure thing" but Git has been around since 2005, I wouldn't call it "another VCS". It's likely the de facto standard.
Should it be better? Yes
Is it the user's fault if they don't get it? Not at all. Judging from the popularity of git tutorials even on dev.to, is pretty obvious that it's a complicated tool and it should be better. As I said, I don't get it 100% either.
Should you learn its main features nonetheless? Yeah.
Is it a fair world? Nope :D
This value of being distributed is something I don't really understand. It sure makes sense in the open source world. But in professional software development with teams of 2 to 20 developers working closely together, it is important to make your code available for other team members as soon as possible instead of keeping it in your local repository
I wouldn't separate open source from "professional software development" but that's an entirely different conversation :D
I agree with you that most teams use Git as it were a centralized repo but this doesn't remove the advantages of the "distributed" part of source control:
there is value in having a complete copy of the repository at all times
there is value in being able to commit to your own copy and then sync to the designated main repository
Subversion was perfectly fine for the team, until it wasn't. Git is probably over-engineered for many teams, until things start going really south.
Maybe the biggest advantage of DVCS isn't the "offline thing" but the fact they enable any sort of branching model which can be modeled on top of any company's structure.
I think the way forward should be better tooling on top of a DVCS.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Three reasons: most open source projects are on github, the herd effect and because it's not that complicated in the day to day. The most complicated thing about Git is rebasing but even that is not rocket science, you just need to read a decent tutorial about it and keep practicing (the fact that it should be infinitely simpler is a given)
I don't think I know more than half of what git is capable of and I'm able to work with it every day.
Git's UI admittedly isn't great but you can use a few aliases to make your life better.
Totally disagree :-D Getting source control right (be it subversion or git or whatever) is very important. Even the fact that you can go back in time is something you should know how to do and can be valuable to your or your employer.
Subversion is much better these days then when Git came around but there's value in the "distributed" part of source control. Maybe Git isn't the best one (Mercurial is cool, bazaar is another contender) but as often happens with competing technologies, one gets more popular than the others, not always because of "absolute merits".
I don't think this is a fair argument, not enough to dismiss Git though. If we apply it to every technology, innovation wouldn't ever happen. We are software developers, we can't dismiss a technology because is more complicated. Though I don't like complexity for complexity's sake, "being more complex" than Subversion despite being a fundamentally different tool isn't ground for automatic dismissal. Maybe there are companies that could just as well use subversion as they use git, but most likely they are developers who already know how to manage and maintain a git based source tree, hence that's what they end up doing
"Convention over configuration", you just decide that one of the repos is the central one.
We could make the same exact argument for auto incrementing numeric IDs and UUIDs, but honestly... didn't we solve this a thousand year ago? It's not like I'm going around memorizing which commit has which ID. We use the message of the commmit and its timestamp because we're humans and not machines.
This I agree with :D It's truly bad. Mercurial's UI made more sense to me
Thanks for the detailed answer. You have made some very good points.
I have no doubt that it is important but as a developer I don't want to spend more time and effort on it than absolutely neccessary. It is more of an infrastructure thing. It is also important that someone keeps the servers running and that someone cleans the toilets at the office. Most developers are probably more interested learning a new programming language, framework or some other development technique than learning another VCS.
This value of being distributed is something I don't really understand. It sure makes sense in the open source world. But in professional software development with teams of 2 to 20 developers working closely together, it is important to make your code available for other team members as soon as possible instead of keeping it in your local repository. I know you can work with Git in a centralized way but in this case you don't really need a distributed VCS. Being able to work offline is no big deal anymore and will probably be even less important in the future.
Sure, and I understand your earlier point about "infrastructure thing" but Git has been around since 2005, I wouldn't call it "another VCS". It's likely the de facto standard.
Should it be better? Yes
Is it the user's fault if they don't get it? Not at all. Judging from the popularity of git tutorials even on dev.to, is pretty obvious that it's a complicated tool and it should be better. As I said, I don't get it 100% either.
Should you learn its main features nonetheless? Yeah.
Is it a fair world? Nope :D
I wouldn't separate open source from "professional software development" but that's an entirely different conversation :D
I agree with you that most teams use Git as it were a centralized repo but this doesn't remove the advantages of the "distributed" part of source control:
There's also the fact that branching and merging tends to be better with distributed source control. I have many non fond memories of Subversion's problems with merging and file locking and we were around 10 devs. I'm perfectly fine if we don't go back :-)
Subversion was perfectly fine for the team, until it wasn't. Git is probably over-engineered for many teams, until things start going really south.
Maybe the biggest advantage of DVCS isn't the "offline thing" but the fact they enable any sort of branching model which can be modeled on top of any company's structure.
I think the way forward should be better tooling on top of a DVCS.