4 ms·

SVN is one of the sanest and most robust VCSes there is. If even that leads to disaster, then throwing git at the team will only make things worse. You need to

SVN is one of the sanest and most robust VCSes there is. If even that leads to disaster, then throwing git at the team will only make things worse. You need to educate them about proper VCS use instead. We've recently transitioned to git at work and a couple of weeks later I'm already stuck in a week-long repository cleanup project on one of the central repositories because people just created a phenomenally huge mess in it. They were experienced and happy SVN users before, but somehow the boss forced the git hype train on us and has to pay the price now.

kevin_thibedeau 8y ago
It is not sane. They created a low level versioned network filesystem and then never bothered to implement branching, tagging, or merging in a workable way. In 2018 I still get bogus merge conflicts if someone before me didn't commit things just so.
- gmueckl 8y ago
  SVN has quite workable branching and tagging, as opposed to git. Refs are just a nightmare to work with. The mental overhead that their utterly broken logic creates is astonishing.
- xorcist 8y ago
  It might be helpful if you could spell out why the branching, tagging and merging of svn isn't workable for you. It's clearly worked for many people and large projects for a number of years. Linus didn't set out to create git because of some missing features in svn, but because he wanted a fundamentally different tool. If you find yourself with merges that are clean in version control system but creates conflicts in another, which is entirely possible, you are likely doing something very special that isn't a great fit for either. There might be more straightforward process to follow that doesn't end up with such difficult merges. Maybe it's just merging more often, maybe it's something else. But it's very easy to blame the tools when the processes are broken.
  - lsh 8y ago
    > Linus didn't set out to create git because of some missing features in svn, but because he wanted a fundamentally different tool. Whoa whoa whoa, hold up there. Linus isn't some VCS visionary, he didn't magic the idea of distributed VCS out of thin air. There were plenty of other DVCS out there at the time, he just built another one.
jogjayr 8y ago
Having worked in both git and SVN shops, SVN is adequate as a server-side VCS. Most of the time you don't need branches on the server side. However, using only SVN client-side is absolute misery - no interactive rebasing, local commits, local branches, stashing, or committing specific lines from a file. You absolutely have to use something like git-svn or hg-svn to be productive. The other (and this is a major one) downside of adopting SVN for your org is the dearth of decent tools for code review and collaboration. At a previous company we used Fisheye/Crucible which is seriously not fit for purpose. At another SVN shop I worked at, we emailed patches to each other (seriously). And the lack of quality tooling is down to SVN's declining popularity - there's no market.
- jdc0589 8y ago
  > most of the time you don't need branches on the server side what?
  - jogjayr 8y ago
    You're better off releasing from trunk/head/master than cutting a release branch. And if you are cutting a release branch, you don't need to merge it so SVN branching is adequate, if still unpleasant and awful to use. The only other use-case for server-side branches is collaborating with team-mates on a long-lived feature. Feature flags work well enough for this and you should probably be using them anyway.
- gmueckl 8y ago
  The lack of good tooling for SVN is because git is so utterly inadequate at doing it's job. So this created a need for a ton of tools that pave over those flaws and now the resulting ecosystem is a money making machine.
  - jogjayr 8y ago
    You're saying git is so bad that an ecosystem sprung up to support it? But if it's so bad why would it have a large enough userbase to support that ecosystem? That logic seems backwards.

kevin_thibedeau 8y ago

It is not sane. They created a low level versioned network filesystem and then never bothered to implement branching, tagging, or merging in a workable way. In 2018 I still get bogus merge conflicts if someone before me didn't commit things just so.

gmueckl 8y ago
SVN has quite workable branching and tagging, as opposed to git. Refs are just a nightmare to work with. The mental overhead that their utterly broken logic creates is astonishing.
xorcist 8y ago
It might be helpful if you could spell out why the branching, tagging and merging of svn isn't workable for you. It's clearly worked for many people and large projects for a number of years. Linus didn't set out to create git because of some missing features in svn, but because he wanted a fundamentally different tool. If you find yourself with merges that are clean in version control system but creates conflicts in another, which is entirely possible, you are likely doing something very special that isn't a great fit for either. There might be more straightforward process to follow that doesn't end up with such difficult merges. Maybe it's just merging more often, maybe it's something else. But it's very easy to blame the tools when the processes are broken.
- lsh 8y ago
  > Linus didn't set out to create git because of some missing features in svn, but because he wanted a fundamentally different tool. Whoa whoa whoa, hold up there. Linus isn't some VCS visionary, he didn't magic the idea of distributed VCS out of thin air. There were plenty of other DVCS out there at the time, he just built another one.

jogjayr 8y ago

Having worked in both git and SVN shops, SVN is adequate as a server-side VCS. Most of the time you don't need branches on the server side. However, using only SVN client-side is absolute misery - no interactive rebasing, local commits, local branches, stashing, or committing specific lines from a file. You absolutely have to use something like git-svn or hg-svn to be productive. The other (and this is a major one) downside of adopting SVN for your org is the dearth of decent tools for code review and collaboration. At a previous company we used Fisheye/Crucible which is seriously not fit for purpose. At another SVN shop I worked at, we emailed patches to each other (seriously). And the lack of quality tooling is down to SVN's declining popularity - there's no market.

jdc0589 8y ago
> most of the time you don't need branches on the server side what?
- jogjayr 8y ago
  You're better off releasing from trunk/head/master than cutting a release branch. And if you are cutting a release branch, you don't need to merge it so SVN branching is adequate, if still unpleasant and awful to use. The only other use-case for server-side branches is collaborating with team-mates on a long-lived feature. Feature flags work well enough for this and you should probably be using them anyway.
gmueckl 8y ago
The lack of good tooling for SVN is because git is so utterly inadequate at doing it's job. So this created a need for a ton of tools that pave over those flaws and now the resulting ecosystem is a money making machine.
- jogjayr 8y ago
  You're saying git is so bad that an ecosystem sprung up to support it? But if it's so bad why would it have a large enough userbase to support that ecosystem? That logic seems backwards.