
Subversion vs. Git: Myths and Facts - sunraa
https://svnvsgit.com
======
jammycakes
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.

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

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

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

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

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

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

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

~~~
jammycakes
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)

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

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

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

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

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

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

------
dev360
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
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
Not technically a project use-case, but the company or department-wide giant
uni-repo is where SVN works well.

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

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

~~~
viraptor
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)

~~~
Const-me
“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](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.

------
benjamincharity
> 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...](https://github.com/blog/1986-announcing-git-large-file-storage-lfs)

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

