> Please, do elaborate! In detail, why is git better than subversion if all I need is a central repository for a few people working at a company on one site, sitting in the same room with permanent network access. No distributed or remote or on-the-go development, no forks.
Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result:
1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change
2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools.
Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice.
However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.
SVN has branches, too. The problem it had was with merge-tracking and that's about when everyone hopped over to git (myself included). But that hasn't been an issue for a couple years now. By all means, stick with git if you prefer it, but release some of the older criticisms as they've been addressed by the SVN team.
You certainly implied a branch-free workflow. Otherwise why would you have a dirty local workspace and multiple checkouts? And why would committing break a build? I'm unaware of any CI server configured to build every branch in the SVN tree.
Do you make a branch every time you change something? Do you make a branch for every developer's local copy?
The thing is, when you solve the problem of dirty local workspaces by making them actual branches svn becomes just as complex as git, probably even more so given that all the branches exist for all the users. And you still don't have has good interface for cherry-picking, you still need multiple local copies, it still isn't as fast and you still don't have all the other benefits associated with a DVCS.
You don't need multiple local copies. That's why "svn switch" exists. That's all I was addressing. Some of the things you knock SVN for are either non-issues or issues with git as well. E.g., "branches exist for all users" is a non-issue. Otherwise it's also a problem when I push a git branch (which is a wise thing to do).
Cherry-picking and speed are legitimate benefits of git.
Because with svn you end up having dirty working directories that go uncommitted for days because committing would break the build, as a result:
1. Everyone ends up making a second working directory because the first one they have is dirty with changes they can't yet commit and they need to make a quick change
2. Those dirty working directories are branches in practice, even if svn doesn't call them that, they are just dealt with with inferior tools.
Also: cherry picking commits from a branch into another branch isn't as easy, making a new repository isn't as easy, git is way faster at (almost?) everything (including large binary files), and being able to check the history when you are not in the office or connected to the VPN is nice.
However, I agree that the conceptual model behind DVCS is harder to understand, significantly harder, svn can be good enough especially for a small, local team.