4 ms·

I think one has to work a little without a tool to truly understand why the tool has exists. Many new developers are forced to use git and they just don't under

I think one has to work a little without a tool to truly understand why the tool has exists. Many new developers are forced to use git and they just don't understand why they have to go through this painful process. I started without version control. I very quickly realised that it's very easy to break a project but forget how to undo your latest breaking changes. I discovered subversion and it was amazing. It was 2006 and I was the only person on my course to my knowledge who was using version control. At around that time git came out and some people were trying it but many people said it was completely unnecessary for most projects. I then tried to use svn for a project with more than just myself as a developer and it was a disaster. We had giant commits once a day that cause conflicts every time. It was horrible. Git was truly amazing. I agree the cli isn't great (I use magit) but you have to have lived without it to understand why it's so important.

setquk 8y ago
I’ve built some big things on SVN. The same mistakes you make in SVN are totally portable to git as well. This isn’t talked about much because people are too ashamed to admit that it wasn’t the tools and was the process and management of the project that caused carnage. I’ve seen this three times now. The best and simultaneously the worst feature of git is the offline commit ability.
gmueckl 8y ago
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.

setquk 8y ago

I’ve built some big things on SVN. The same mistakes you make in SVN are totally portable to git as well. This isn’t talked about much because people are too ashamed to admit that it wasn’t the tools and was the process and management of the project that caused carnage. I’ve seen this three times now. The best and simultaneously the worst feature of git is the offline commit ability.

gmueckl 8y ago

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.