5 ms·

I'll second your suggestion that centralized version control systems have advantages for small projects. I use SVN for most of my personal projects, because no

I'll second your suggestion that centralized version control systems have advantages for small projects. I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.) The simplicity is a major benefit. The main downside is how condescending some Git users can be to SVN users. When I mention I use SVN, I often hear nonsense like "Oh, you must not understand tree structures." Actually, I do, and I see that they have no benefit for certain things I'm working on. The one thing I'd like is the ability to commit without an internet connection, which distributed systems can easily do. But this hasn't been enough of an issue to motivate a switch.

GordonS 8y ago
I resisted moving from SVN to Git for my personal projects for a long time, mainly because I was too lazy. But conflicts or repos getting into an inconsistent state that required fixing was too regular an occurrence, and eventually I snapped. I agree that the mental model with SVN is much simpler that Git, and I used SVN on Windows with AnhkSVN and TortoiseSVN, so maybe it works better on Linux
deleted 8y ago
[deleted]
gkya 8y ago
In both CVS and Svn you can just check out from a local directory. For a couple years I used CVS for my private local repos where CVSROOT was sth. like /my/cvsroot. Same is possible with Svn too.
- otterlicious 8y ago
  The SVN documentation (used to) warn that concurrent access in this configuration could lead to data loss. Even though I'm the only human who accessed my repository I did use scripts, so I always avoided this setup because of that.
paganel 8y ago
> I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.) Same here, I have used the SVN + Trac combination for my personal projects for almost 12 years now, it isn’t broken for me so why should I ever think of fixing it?
otterlicious 8y ago
For me it was my personal projects that made me switch to git. I was tired of maintaining a SVN server just for myself. With git you don't need a server at all, your full repository is locally stored and you can just back it up like you do everything else.
- btrettel 8y ago
  I don't find the maintenance burdensome. I keep my software up to date, including Git, so this isn't an argument against SVN. And I run a weekly backup script that first checks the integrity of the repositories. (This check was motivated by a hard drive failure which caused a small amount of data loss. Git probably would have helped in this case, but now I think I'm good.) I haven't done much anything else specifically for SVN in the past 5 years.
  - otterlicious 8y ago
    To be fair, most of my issues were with Apache, not SVN itself. The most egregious thing I remember was that Apache changed configuration directives twice during the time I maintained it in a way that broke my SVN server, but there were plenty of other papercuts. This was also during SVN's heydey. I'm sure it's much more stable now. ;-)
- pjmlp 8y ago
  You also don't need a server for SVN, it can use another directory as repository.
HelloNurse 8y ago
My recollections of using Subversion, a few years ago, are mainly about terrible performance and frequent unrecoverable damage to working copies and repositories. "Atomic" commits appeared to be named for their ability to leave a radioactive wasteland behind them. And of course, a policy of not branching because it's difficult and dangerous doesn't mean taking advantage of simplicity.
- Reason077 8y ago
  Managing branches is a pain with subversion compared to git, sure. But dangerous? There are major projects out there still using subversion. GCC for example. They have lots of branches. As for performance... well, svn is way better than CVS.
- btrettel 8y ago
  Sounds to me like you didn't know what you were doing with SVN. If I complain that Git caused some problems, Git users are likely (and often justified) to tell me that I was using Git wrong. But it's rare that the same reasoning is extended towards SVN by many Git users. The worst I've had with SVN was a broken working copy, which is usually easily fixed. With Git, problems like that occur much more frequently. In the past 6 months I likely have completely wiped my local Git repository for a particular project alone more times than I've ever had to fix a broken SVN working copy. My experience is closer to the famous XKCD comic: https://xkcd.com/1597/ https://xkcd.com/1597/ Now, perhaps you could argue that I don't understand Git well enough, and I wouldn't necessarily argue against that. I think Git has a terrible and confusing UI compared against other distributed systems. (And the simplicity of SVN makes its UI good, I think.) As for performance, again, I use SVN with small projects, so performance hasn't been an issue. To be honest, I probably save time compared against Git from not having to type as much with SVN! And I don't branch in SVN because I don't want to, not because it's difficult or dangerous. Branching would provide no benefit in my case. If I wanted to branch, I'd switch to a distributed system. My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
  - baseballdork 8y ago
peatmoss 8y ago
SVN also maintains one killer advantage over git to this day: Storing large binary files. - Data scientists and researchers who want to check in the original products of data collection, cleanup, etc. - Software with large artistic assests like audio, textures, and other visual art. I think about the reproducible research movement and think to myself that SVN is strictly better for many such projects.
- andrewaylett 8y ago
  At least git stores its local copy of the repository compressed -- svn keeps a second uncompressed copy of the current revision, to be able to run a diff. So neither are great for large binaries, although at least subversion will only grab the latest. But use of compression and binary deltas does mean that (for regular text-based code) a git checkout including all history can be smaller than a subversion checkout with just the latest version.
- adrianmsmith 8y ago
  And Subversion, being centralized, allows you to opt-in to a "lock, change, commit" workflow, on a file-per-file basis, or on basis of file-type. Which is great for binary files, as pretty much any binary file such as Excel sheets or Photoshop documents or even PNG assets can't be easily merged, so Git's "work independently, then merge later" workflow can never work with those files.
deleted 8y ago
[deleted]

GordonS 8y ago

I resisted moving from SVN to Git for my personal projects for a long time, mainly because I was too lazy. But conflicts or repos getting into an inconsistent state that required fixing was too regular an occurrence, and eventually I snapped. I agree that the mental model with SVN is much simpler that Git, and I used SVN on Windows with AnhkSVN and TortoiseSVN, so maybe it works better on Linux

deleted 8y ago

[deleted]

gkya 8y ago

In both CVS and Svn you can just check out from a local directory. For a couple years I used CVS for my private local repos where CVSROOT was sth. like /my/cvsroot. Same is possible with Svn too.

otterlicious 8y ago
The SVN documentation (used to) warn that concurrent access in this configuration could lead to data loss. Even though I'm the only human who accessed my repository I did use scripts, so I always avoided this setup because of that.

paganel 8y ago

> I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.) Same here, I have used the SVN + Trac combination for my personal projects for almost 12 years now, it isn’t broken for me so why should I ever think of fixing it?

otterlicious 8y ago

For me it was my personal projects that made me switch to git. I was tired of maintaining a SVN server just for myself. With git you don't need a server at all, your full repository is locally stored and you can just back it up like you do everything else.

btrettel 8y ago
I don't find the maintenance burdensome. I keep my software up to date, including Git, so this isn't an argument against SVN. And I run a weekly backup script that first checks the integrity of the repositories. (This check was motivated by a hard drive failure which caused a small amount of data loss. Git probably would have helped in this case, but now I think I'm good.) I haven't done much anything else specifically for SVN in the past 5 years.
- otterlicious 8y ago
  To be fair, most of my issues were with Apache, not SVN itself. The most egregious thing I remember was that Apache changed configuration directives twice during the time I maintained it in a way that broke my SVN server, but there were plenty of other papercuts. This was also during SVN's heydey. I'm sure it's much more stable now. ;-)
pjmlp 8y ago
You also don't need a server for SVN, it can use another directory as repository.

HelloNurse 8y ago

My recollections of using Subversion, a few years ago, are mainly about terrible performance and frequent unrecoverable damage to working copies and repositories. "Atomic" commits appeared to be named for their ability to leave a radioactive wasteland behind them. And of course, a policy of not branching because it's difficult and dangerous doesn't mean taking advantage of simplicity.

Reason077 8y ago
Managing branches is a pain with subversion compared to git, sure. But dangerous? There are major projects out there still using subversion. GCC for example. They have lots of branches. As for performance... well, svn is way better than CVS.
btrettel 8y ago
Sounds to me like you didn't know what you were doing with SVN. If I complain that Git caused some problems, Git users are likely (and often justified) to tell me that I was using Git wrong. But it's rare that the same reasoning is extended towards SVN by many Git users. The worst I've had with SVN was a broken working copy, which is usually easily fixed. With Git, problems like that occur much more frequently. In the past 6 months I likely have completely wiped my local Git repository for a particular project alone more times than I've ever had to fix a broken SVN working copy. My experience is closer to the famous XKCD comic: https://xkcd.com/1597/ https://xkcd.com/1597/ Now, perhaps you could argue that I don't understand Git well enough, and I wouldn't necessarily argue against that. I think Git has a terrible and confusing UI compared against other distributed systems. (And the simplicity of SVN makes its UI good, I think.) As for performance, again, I use SVN with small projects, so performance hasn't been an issue. To be honest, I probably save time compared against Git from not having to type as much with SVN! And I don't branch in SVN because I don't want to, not because it's difficult or dangerous. Branching would provide no benefit in my case. If I wanted to branch, I'd switch to a distributed system. My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
- baseballdork 8y ago

peatmoss 8y ago

SVN also maintains one killer advantage over git to this day: Storing large binary files. - Data scientists and researchers who want to check in the original products of data collection, cleanup, etc. - Software with large artistic assests like audio, textures, and other visual art. I think about the reproducible research movement and think to myself that SVN is strictly better for many such projects.

andrewaylett 8y ago
At least git stores its local copy of the repository compressed -- svn keeps a second uncompressed copy of the current revision, to be able to run a diff. So neither are great for large binaries, although at least subversion will only grab the latest. But use of compression and binary deltas does mean that (for regular text-based code) a git checkout including all history can be smaller than a subversion checkout with just the latest version.
adrianmsmith 8y ago
And Subversion, being centralized, allows you to opt-in to a "lock, change, commit" workflow, on a file-per-file basis, or on basis of file-type. Which is great for binary files, as pretty much any binary file such as Excel sheets or Photoshop documents or even PNG assets can't be easily merged, so Git's "work independently, then merge later" workflow can never work with those files.

deleted 8y ago

[deleted]