Subversion vs. Git: Myths and Facts | Hacker News Reader

Subversion vs. Git: Myths and Facts

svnvsgit.com

29 pointssunraa36 comments

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.

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.

If you stick to the rules, and you have only one branches/tags/trunk structure in your repo, and you actually set up the branches/tags/trunk structure in the first place, yes.

But my whole point is that there's far too much scope to get it wrong in ways that can be difficult to fix.

If you have multiple projects in your repo, svn cp and svn switch become cumbersome.

Many people check out the root folder with the entire structure and all the branches, and not just trunk.

I've seen projects that have nested branches/tags/trunk structures.

I've seen people check code in to two branches at once.

I've seen people "branch" by physically copying the files client-side then checking in the result. Losing the relationship between the branches that they need to merge successfully.

If you check in the merge then find you've messed it up, you can't roll back and start over without cluttering up your source history. And even then, how to do that is non-obvious and easy to get wrong.

And people DO make these mistakes repeatedly because svn treats branching and merging as an advanced technique. The first several times you do it, you invariably mess up, and leave a permanent record of how you messed up. Very often it's not you who learns that you've messed up but a colleague who does the merge. And once you learn to get it right, someone else on your team comes along and they get it wrong. The feedback loop is terrible.

Whereas with git it's a core competency so you learn you've messed up fairly quickly. And offline commits let you easily roll back when you do. The feedback loop is rapid and effective.

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.

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?

They said UI, not GUI. Command line is still a user interface.

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.

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.

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".

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.

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.

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.

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

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/CHANGE...

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).

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...

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

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.

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.

The "Paid for by Apache Subversion" is missing in the footer :)

More seriously, some interesting myth busting, but I still prefer a distributed model.

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.

> 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.

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

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.

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.

Not technically a project use-case, but the company or department-wide giant uni-repo is where SVN works well.

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

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)?

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.

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`

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.

As mentioned in other comments - powershell terminal is your terminal. As for the issue - if you can't define what files have what encoding, how do you expect git to know it?

What you can do is apply the binary filter I posted to all files and write a script which attempts to guess encoding and then translates that to utf16 with iconv. But expect funny failures from time to time (sometimes more than one decode may be valid)

“if you can't define what files have what encoding” — I can, but not by name or extension. See this: http://unicode.org/faq/utf_bom.html#bom1

“you can do is apply the binary filter I posted to all files and write a script” — yes, I know git is open source and very flexible. But Unicode is 20 years old standard widely accepted by the industry. Git should support Unicode out of the box, without my custom scripts.

Powershell is a terminal?

> 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-stora...

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.

Reply on news.ycombinator.com