5 ms·

> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.

by rhabarba 7y ago

wtetzner 7y ago
How so?
- rhabarba 7y ago
  Less overhead, a better UI.
  - peatmoss 7y ago
    Better support for large and binary artifacts
  - c-cube 7y ago
    horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.
kstrauser 7y ago
Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.
- codazoda 7y ago
  I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
  - kstrauser 7y ago
    Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.
    - TwoHeadedBeast 7y ago
      Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.
  - duskwuff 7y ago
    Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.
    - yjftsjthsd-h 7y ago
      Yeah, other than locking I would argue that a DVCS is better at even the things a non-distributed VCS is good at.
    - TwoHeadedBeast 7y ago
      The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.
      - adrianmsmith 7y ago
        Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)
kempbellt 7y ago
> Which is a better choice than Git for most projects, to be honest. That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience. Really depends on where/how you're using versioning, team familiarity, etc.
- hinkley 7y ago
  It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system. That’s a little too much to explain away with variability.
lmm 7y ago
Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).
- bhaak 7y ago
  If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.
  - lmm 7y ago
    SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.
    - bhaak 7y ago
      Sure but you could say the same about Git. With time, the standard requirements rise and we get more demanding. How about a VCS that not only diffs line by line but saves the diffs as editing delta? Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change? Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.

> unfortunately still Subversion Which is a better choice than Git for most projects, to be honest.

wtetzner 7y ago

How so?

rhabarba 7y ago
Less overhead, a better UI.
- peatmoss 7y ago
  Better support for large and binary artifacts
- c-cube 7y ago
  horrendously slow `svn log`, locking files, bad branching… I only used it when I was a student but I don't miss svn at all.

kstrauser 7y ago

Everyone's has their own tastes and preferences, of course, and I respect that yours is different than mine. That said, I used and loved CVS and then SVN for years and didn't get why all the kids were fussing around with this new Git thing. I finally made myself try it for about a week. At the end of that experiment, I ported all my repos from SVN to Git and quickly set to purging all Subversion-related knowledge from my brain. There's literally nothing about SVN that I prefer to Git, other than its UI was a little more pleasant.

codazoda 7y ago
I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
- kstrauser 7y ago
  Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.
  - TwoHeadedBeast 7y ago
    Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.
- duskwuff 7y ago
  Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.
  - yjftsjthsd-h 7y ago
    Yeah, other than locking I would argue that a DVCS is better at even the things a non-distributed VCS is good at.
  - TwoHeadedBeast 7y ago
    The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.
    - adrianmsmith 7y ago
      Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)

kempbellt 7y ago

> Which is a better choice than Git for most projects, to be honest. That's pretty subjective. Most engineers I interact with personally know how to use Git but not SVN. I'd argue the opposite is true base on my subjective experience. Really depends on where/how you're using versioning, team familiarity, etc.

hinkley 7y ago
It took me maybe eight months before I was willing to perform open heart surgery on a subversion repo. Two years to dare to try the same thing with git, and I was much more anxious about the whole thing. At the three year mark I have the same ambivalence about things working out that I did in less than a quarter of the time with the previous system. That’s a little too much to explain away with variability.

lmm 7y ago

Disagree. SVN was always a pain. Committing is really slow and merging is bad (particularly for things like directory renames).

bhaak 7y ago
If all you had before was CVS then SVN wasn't a pain. Atomic commits and file renames.
- lmm 7y ago
  SVN had improvements over CVS, but it still had obvious pain points. So there was still an obvious opportunity for a better VCS to come along.
  - bhaak 7y ago
    Sure but you could say the same about Git. With time, the standard requirements rise and we get more demanding. How about a VCS that not only diffs line by line but saves the diffs as editing delta? Or that understands the syntax of the code and can differentiate a variable renaming from an actual code change? Or connecting different repositories is hardly solved with Git. Submodules suck, grafting even more so. Or you can't make one repository out of two and keep their Git history intact.