9 ms·

Subversion vs. Git: Myths and Facts

29 points by sunraa 10y ago

dudul 10y ago
The "Paid for by Apache Subversion" is missing in the footer :) More seriously, some interesting myth busting, but I still prefer a distributed model.
- runin2k1 10y ago
  I like both technologies for various reasons, but as a propaganda piece for SVN this should effectively reinforce SVN users decision to use SVN while Git users will see it as blatant FUD-mongering. Meaning net zero for both sides.
Someone1234 10y ago
With the CURRENT version of Subversion, do they allow you to do offline commits? Specifically if I am taking the train into work, connectivity is spotty, with git I can commit as many times as needed against my local offline repository then push it once I am online. That didn't used to be true with Subversion, but it may have changed. Thus my question.
- lantastic 10y ago
  Changelog[1] up to current (1.9.4) doesn't have offline commits. Not sure if anything like that is even on the svn roadmap. [1] http://svn.apache.org/repos/asf/subversion/tags/1.9.4/CHANGES http://svn.apache.org/repos/asf/subversion/tags/1.9.4/CHANGE...
- jammycakes 10y ago
  No they don't. Shelving and checkpointing have been planned for Subversion for several years now and though they're currently slated for version 1.10, currently in development, work on those features hasn't started yet. Given that it's been bounced from 1.9 already, and that Subversion release cycles are measured in geologic eras, I'm not holding my breath. Source: http://subversion.apache.org/roadmap.html http://subversion.apache.org/roadmap.html
dev360 10y ago
"Due to historical reasons, Subversion doesn’t properly track file and folder renames (mostly because file renames rarely happened before refactorings were invented)."
- infogulch 10y ago
  I was about to quote this exact line. I mean, what the hell? "before refactorings were invented" The idea that someone invented the concept (not name) of refactoring is nonsensical to me. It comes naturally from normal maintenance, or changing requirements, not something that needs to be invented.
  - prodigal_erik 10y ago
    Renaming was rarely done because devs advised each other to avoid the agony imposed by the tools of the era. The workaround is ridiculous. Trunk should be what's already deployed to prod and known to work.
dev360 10y ago
I recently worked with SVN after 6-7 years with git. Working with branches was a nightmare in comparison to git and felt incredibly cumbersome.
- draw_down 10y ago
  I worked with svn for years and I'm having a real hard time coming up with a project use case where SVN would be preferable. Between hg and git is a much closer comparison, but svn, no way. Sometimes it's OK to just say one thing is better than another.
  - gte525u 10y ago
    Not technically a project use-case, but the company or department-wide giant uni-repo is where SVN works well.
sgillen 10y ago
This reads like an advertisement for svn more than anything. There's nothing wrong with trying to dispell some myths about svn, but the author should be up front about it.
- HelloNurse 10y ago
  At least the site's anonymous author cherrypicks some biased but reasonably true statements to make instead of spreading opinions and misinformation. I'd still like to see entries for some elephants in the room like "Subversion is far slower than Git in important operations", "Common failure types corrupt Subversion working copies" and "Locked files interfere with team workflow".
jammycakes 10y ago
Number 2 makes me laugh: "Branches are expensive in Subversion - False. A Myth." Totally misses the point that the expense of branching and merging in Subversion is all in the UI/UX. Not only is it horribly cumbersome, it's also much easier to get it wrong, not obvious that you are getting it wrong, and harder to recover once you've discovered you've got it wrong.
- veli_joza 10y ago
  SVN is command line tool, just like Git. Which UI are you talking about? TortoiseSVN? Or are you talking about commands and parameters to svn executable?
  - pimlottc 10y ago
    They said UI, not GUI. Command line is still a user interface.
- mikestew 10y ago
  Cumbersome merging/branching and offline commits are the only two things I need to know to not use SVN (or CVS, Team Foundation Server, et. al.). Maybe I have the git version of Stockholm Syndrome (and after, what, seven or eight years I probably do), but I recall dreading a non-trivial merge, and to a lesser extent branching, in SVN due to cumbersome UI and an easy path to getting it wrong. And if your SCM doesn't let me work on the bus, GTFO.
- RJIb8RBYxzAMX9u 10y ago
  Would you kindly clarify? Branching and merging in svn seems perfectly obvious to me: $ cd trunk-wc $ svn cp ^/trunk ^/branches/my-topic # create my-topic branch $ svn switch ^/branches/my-topic # switch working copy to my-topic $ # Hack away $ svn commit -m "My awesome new feature." $ svn switch ^/trunk # switch working copy to trunk $ svn merge ^/branches/my-topic ^/trunk # merge topic branch changes to trunk (a) $ svn commit -m "Merge awesome feature from my-topic." In step (a), resolve any conflicting files with svn resolve; to start over, do svn revert [-R] (granted, new files will be left behind and there's no git clean equivalent AFAIK). With the exception of svn cp, all the commands are self-describing (and with svn cp, someone argued in the BK open-sourcing thread that "a branch is a copy" model is fairly intuitive for even non-technical users). I concede that git is more powerful and supports different branch / merge workflows than svn, but svn's hardly horrible.
jfrisby 10y ago
So I cloned the WordPress git repo and noticed immediately that neither the size of the `.git` directory nor the total size (working copy + `.git` directory) was as large as the article claims. Instead of 32,647 commits, the number at the time I cloned it was 37,304 (`git rev-list --all | wc -l`), or 34,165 reachable from HEAD (`git rev-list HEAD | wc -l`), yet the total size was 162M (`du -hs .`) -- a bit smaller than the 169.7M cited in the article. Further, if I re-compress everything (`git gc --aggressive`) then the total size decreases to 117M. That is a sizable difference to begin with -- and doubly-so given that it represents more commits than either of the repositories in the original comparison.
Const-me 10y ago
With the current version of git, have they already implemented Unicode support? Last time I checked, git treats UTF-16 text as binary.
- viraptor 10y ago
  What do you mean by "unicode support"? git stores data, whatever encoding they use and that's it. The display part is up to you and none of the usual tools support utf-16 by default. Have you tried some tools that detect the encoding for you (like vimdiff)?
  - Const-me 10y ago
    By "unicode support" I mean here on Windows 10 PC I’d like "git log -p" print to the PowerShell those changed lines + line numbers, like it works with ASCII files.
    - viraptor 10y ago
      That can be handled by gitattributes already. Something like this should help: [diff "the_file_extension"] textconv = the_conversion_tool binary = true You just need to find/write the conversion utility you need. iconv could do that with `iconv -f UTF-16 -t your-terminal-encoding`
      - Const-me 10y ago
        No it can’t, because of the following two things: (1) Not all source or text files are Unicode, I can’t assign an extension. (2) I’m running Windows, I don’t have terminal, I use git from power shell. And power shell’s native encoding is already UTF-16.
        dkuntz2 10y ago
        Powershell is a terminal?
        10y ago
RaycatRakittra 10y ago
This definitely feels like an advertisement for Subversion. It spins all of these comparisons against Git.
theneb 10y ago
This article suffers from major bias and is pure conjecture from the authors perspective. I could counter argue with many reasons why git/hg/perforce/cvs is superior but it misses the core point about any VCS. It's about team collaboration and different tools suit different teams.
froh42 10y ago
Does svn still force me to update before I commit (and possibly fuck up and destroy my changes) when there are conflicting changes with upstream? Being able to commit first and then care about conflicts second is my biggest selling point for DVCS (git/hg).
- douche 10y ago
  Yup, you still have to update before you can commit. And it still sucks awful when you've got two or more people working in the same area... So it's still: do some work, go to check in, see that there's an upstream conflict, curse, copy your working copy of the conflicted file into a notepad buffer, just in case, try to update, spend the next 15 minutes verifying that stuff didn't get hosed, and fix it if necessary, then go to try to commit again... And sometimes there's another conflict...
Walkman 10y ago
The "fact" about the sizes are total bullshit. Last time I checked, SVN repo was 3x larger (1,5Gb vs 4,5Gb) and a whole fucking lot slower.
mikestew 10y ago
Dispel all the myths you want, but until you dispel the "SVN can't do offline commits", I have no use for it. That's the only reason I read the article, to find out that I'm behind the times and SVN finally caught up ten years later. Alas, it's simply, "see, SVN is just as good as git, and better in exactly one respect (huge monolithic repos)", except still severely lacking what is common use case for me.
benjamincharity 10y ago
> Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files). Does this still hold true now that GitHub handles large binary files? https://github.com/blog/1986-announcing-git-large-file-storage-lfs https://github.com/blog/1986-announcing-git-large-file-stora...
jdbernard 10y ago
> An outdated myth. Don't you mean an outdated fact, since it was true. > Certain workflow limitations exist. Also true of SVN. I'd argue it is more true of SVN than Git, but whatever. > Git history is not safe You gave so much leniency to subversion for half-truths earlier, but you're going to come down on Git for this? `rebase` does not destroy history. `commit --amend` does not destroy history. `filter-branch` does not destroy history. The old commits are still there. You can easily find them with `reflog`. `reset --hard` doesn't even add new commits, just changes where a branch pointer points. As identified by others in this thread, this is really cherry-picking the issues and totally ignoring some major flaws and drawbacks specific to SVN that led to DVCS's in the first place. If it wasn't already obvious that this was a biased piece, you include only negeative experiences with git in your "further reading" section.

29 points by sunraa 10y ago

dudul 10y ago

The "Paid for by Apache Subversion" is missing in the footer :) More seriously, some interesting myth busting, but I still prefer a distributed model.

runin2k1 10y ago
I like both technologies for various reasons, but as a propaganda piece for SVN this should effectively reinforce SVN users decision to use SVN while Git users will see it as blatant FUD-mongering. Meaning net zero for both sides.

Someone1234 10y ago

With the CURRENT version of Subversion, do they allow you to do offline commits? Specifically if I am taking the train into work, connectivity is spotty, with git I can commit as many times as needed against my local offline repository then push it once I am online. That didn't used to be true with Subversion, but it may have changed. Thus my question.

lantastic 10y ago
Changelog[1] up to current (1.9.4) doesn't have offline commits. Not sure if anything like that is even on the svn roadmap. [1] http://svn.apache.org/repos/asf/subversion/tags/1.9.4/CHANGES http://svn.apache.org/repos/asf/subversion/tags/1.9.4/CHANGE...
jammycakes 10y ago
No they don't. Shelving and checkpointing have been planned for Subversion for several years now and though they're currently slated for version 1.10, currently in development, work on those features hasn't started yet. Given that it's been bounced from 1.9 already, and that Subversion release cycles are measured in geologic eras, I'm not holding my breath. Source: http://subversion.apache.org/roadmap.html http://subversion.apache.org/roadmap.html

dev360 10y ago

"Due to historical reasons, Subversion doesn’t properly track file and folder renames (mostly because file renames rarely happened before refactorings were invented)."

infogulch 10y ago
I was about to quote this exact line. I mean, what the hell? "before refactorings were invented" The idea that someone invented the concept (not name) of refactoring is nonsensical to me. It comes naturally from normal maintenance, or changing requirements, not something that needs to be invented.
- prodigal_erik 10y ago
  Renaming was rarely done because devs advised each other to avoid the agony imposed by the tools of the era. The workaround is ridiculous. Trunk should be what's already deployed to prod and known to work.

dev360 10y ago

I recently worked with SVN after 6-7 years with git. Working with branches was a nightmare in comparison to git and felt incredibly cumbersome.

draw_down 10y ago
I worked with svn for years and I'm having a real hard time coming up with a project use case where SVN would be preferable. Between hg and git is a much closer comparison, but svn, no way. Sometimes it's OK to just say one thing is better than another.
- gte525u 10y ago
  Not technically a project use-case, but the company or department-wide giant uni-repo is where SVN works well.

sgillen 10y ago

This reads like an advertisement for svn more than anything. There's nothing wrong with trying to dispell some myths about svn, but the author should be up front about it.

HelloNurse 10y ago
At least the site's anonymous author cherrypicks some biased but reasonably true statements to make instead of spreading opinions and misinformation. I'd still like to see entries for some elephants in the room like "Subversion is far slower than Git in important operations", "Common failure types corrupt Subversion working copies" and "Locked files interfere with team workflow".

jammycakes 10y ago

Number 2 makes me laugh: "Branches are expensive in Subversion - False. A Myth." Totally misses the point that the expense of branching and merging in Subversion is all in the UI/UX. Not only is it horribly cumbersome, it's also much easier to get it wrong, not obvious that you are getting it wrong, and harder to recover once you've discovered you've got it wrong.

veli_joza 10y ago
SVN is command line tool, just like Git. Which UI are you talking about? TortoiseSVN? Or are you talking about commands and parameters to svn executable?
- pimlottc 10y ago
  They said UI, not GUI. Command line is still a user interface.
mikestew 10y ago
Cumbersome merging/branching and offline commits are the only two things I need to know to not use SVN (or CVS, Team Foundation Server, et. al.). Maybe I have the git version of Stockholm Syndrome (and after, what, seven or eight years I probably do), but I recall dreading a non-trivial merge, and to a lesser extent branching, in SVN due to cumbersome UI and an easy path to getting it wrong. And if your SCM doesn't let me work on the bus, GTFO.
RJIb8RBYxzAMX9u 10y ago
Would you kindly clarify? Branching and merging in svn seems perfectly obvious to me: $ cd trunk-wc $ svn cp ^/trunk ^/branches/my-topic # create my-topic branch $ svn switch ^/branches/my-topic # switch working copy to my-topic $ # Hack away $ svn commit -m "My awesome new feature." $ svn switch ^/trunk # switch working copy to trunk $ svn merge ^/branches/my-topic ^/trunk # merge topic branch changes to trunk (a) $ svn commit -m "Merge awesome feature from my-topic." In step (a), resolve any conflicting files with svn resolve; to start over, do svn revert [-R] (granted, new files will be left behind and there's no git clean equivalent AFAIK). With the exception of svn cp, all the commands are self-describing (and with svn cp, someone argued in the BK open-sourcing thread that "a branch is a copy" model is fairly intuitive for even non-technical users). I concede that git is more powerful and supports different branch / merge workflows than svn, but svn's hardly horrible.

jfrisby 10y ago

So I cloned the WordPress git repo and noticed immediately that neither the size of the `.git` directory nor the total size (working copy + `.git` directory) was as large as the article claims. Instead of 32,647 commits, the number at the time I cloned it was 37,304 (`git rev-list --all | wc -l`), or 34,165 reachable from HEAD (`git rev-list HEAD | wc -l`), yet the total size was 162M (`du -hs .`) -- a bit smaller than the 169.7M cited in the article. Further, if I re-compress everything (`git gc --aggressive`) then the total size decreases to 117M. That is a sizable difference to begin with -- and doubly-so given that it represents more commits than either of the repositories in the original comparison.

Const-me 10y ago

With the current version of git, have they already implemented Unicode support? Last time I checked, git treats UTF-16 text as binary.

viraptor 10y ago
What do you mean by "unicode support"? git stores data, whatever encoding they use and that's it. The display part is up to you and none of the usual tools support utf-16 by default. Have you tried some tools that detect the encoding for you (like vimdiff)?
- Const-me 10y ago
  By "unicode support" I mean here on Windows 10 PC I’d like "git log -p" print to the PowerShell those changed lines + line numbers, like it works with ASCII files.
  - viraptor 10y ago
    That can be handled by gitattributes already. Something like this should help: [diff "the_file_extension"] textconv = the_conversion_tool binary = true You just need to find/write the conversion utility you need. iconv could do that with `iconv -f UTF-16 -t your-terminal-encoding`
    - Const-me 10y ago
      No it can’t, because of the following two things: (1) Not all source or text files are Unicode, I can’t assign an extension. (2) I’m running Windows, I don’t have terminal, I use git from power shell. And power shell’s native encoding is already UTF-16.
      - dkuntz2 10y ago
        Powershell is a terminal?
      - 10y ago

RaycatRakittra 10y ago

This definitely feels like an advertisement for Subversion. It spins all of these comparisons against Git.

theneb 10y ago

This article suffers from major bias and is pure conjecture from the authors perspective. I could counter argue with many reasons why git/hg/perforce/cvs is superior but it misses the core point about any VCS. It's about team collaboration and different tools suit different teams.

froh42 10y ago

Does svn still force me to update before I commit (and possibly fuck up and destroy my changes) when there are conflicting changes with upstream? Being able to commit first and then care about conflicts second is my biggest selling point for DVCS (git/hg).

douche 10y ago
Yup, you still have to update before you can commit. And it still sucks awful when you've got two or more people working in the same area... So it's still: do some work, go to check in, see that there's an upstream conflict, curse, copy your working copy of the conflicted file into a notepad buffer, just in case, try to update, spend the next 15 minutes verifying that stuff didn't get hosed, and fix it if necessary, then go to try to commit again... And sometimes there's another conflict...

Walkman 10y ago

The "fact" about the sizes are total bullshit. Last time I checked, SVN repo was 3x larger (1,5Gb vs 4,5Gb) and a whole fucking lot slower.

mikestew 10y ago

Dispel all the myths you want, but until you dispel the "SVN can't do offline commits", I have no use for it. That's the only reason I read the article, to find out that I'm behind the times and SVN finally caught up ten years later. Alas, it's simply, "see, SVN is just as good as git, and better in exactly one respect (huge monolithic repos)", except still severely lacking what is common use case for me.

benjamincharity 10y ago

> Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files). Does this still hold true now that GitHub handles large binary files? https://github.com/blog/1986-announcing-git-large-file-storage-lfs https://github.com/blog/1986-announcing-git-large-file-stora...

jdbernard 10y ago

> An outdated myth. Don't you mean an outdated fact, since it was true. > Certain workflow limitations exist. Also true of SVN. I'd argue it is more true of SVN than Git, but whatever. > Git history is not safe You gave so much leniency to subversion for half-truths earlier, but you're going to come down on Git for this? `rebase` does not destroy history. `commit --amend` does not destroy history. `filter-branch` does not destroy history. The old commits are still there. You can easily find them with `reflog`. `reset --hard` doesn't even add new commits, just changes where a branch pointer points. As identified by others in this thread, this is really cherry-picking the issues and totally ignoring some major flaws and drawbacks specific to SVN that led to DVCS's in the first place. If it wasn't already obvious that this was a biased piece, you include only negeative experiences with git in your "further reading" section.