Menu
Possible Duplicates:
Why is git better than Subversion?
I've already read a lot (not enough to get the perfect picture though) about versioning systems, and the obvious conclusion is that GIT is simply the best. Or Bazaar maybe. Or Mercurial. But if so it was, then nobody would be using SVN, but they still do. Why? I myself have no own opinion on what v.c.s. is generally the best yet because of lack of experience with them. Could you share your thoughts?
671
SVN is better than Git for architecture performance, binary files, and usability. And it may be better for access control and auditability, based on your needs.
Many people prefer Git for version control for a few reasons: It's faster to commit. Because you commit to the central repository more often in SVN, network traffic slows everyone down. Whereas with Git, you're working mostly on your local repository and only committing to the central repository every so often.
SVN also enables you to quickly retrieve versions of a code repository through the checkout process. While SVN doesn't support nested repositories, you can still retrieve and combine changes found in multiple code repositories into one working copy of the code using the command svn:externals.
Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).
I'm currently maintaining a version control service for a U.S. research institution. We're not only supporting SVN in addition to Git and Mercurial, but also CVS.
SVN's "killer feature" among our users is narrow clones. You can make a checkout of just one subdirectory deep in a heirarchy, download only the files related to that directory, and still be able to make commits. Git very recently gave a similar, but not quite as useful variation on this feature called sparse checkouts (see also Sparse checkout in Git 1.7.0?). This lets you filter your working tree, but still forces you to download the entire history of the entire project, which can be prohibitive even when large binaries aren't involved. Mind you, disk is cheap, and if you absorb the hit of the initial clone in advance subsequent pulls are quick enough, but this doesn't help people that went on a trip before they realized they needed to clone, and in any case even Git's sparse checkouts won't let you start your working tree five levels down, so it looks a bit ugly.
In addition, users find authz files easier to write than Git commit hooks, are more comfortable with the SVN syntax and methodology than any DVCS, and perhaps most importantly of all, already have many thousands of commits worth of history in SVN. Experiments in migrating large Subversion repositories to Git or Mercurial have provided mixed results, and these are scientists trying to get work done on their own projects, not donating their time to development of a DVCS.
CVS still has a following for a similar reason. Imagine, as a Git user, having sparse checkouts that also allow you to arbitrarily remap where files in the branch show up in your working tree, using a format that is versioned along with the repository and is distributed with every usual pull, that allows you to write definitions that can have groups that can include other groups, and that only pulls down the files necessary for filesystem placement on a clone. That's straightforward in CVS modules, and impossible in every DVCS. For all the sins of CVS (and believe me, we're quite aware of them, and go out of our way to discourage new CVS projects unless they absolutely can't live without modules), it's impossible to convince a group using that feature to migrate to another version control system.
DVCS software has brought some awesome innovations, but they're also missing things that some developers take for granted. Make sure you know in advance what your requirements are before choosing one.
130
Talking about the company I work for — the biggest reason for using SVN is being able to keep huge, proprietary format, binary files under version control. Specifically, libraries of thousands of CAD files. In this instance, it does make sense to have the VCS be file-based like SVN is, rather than textual-information-based like Git.
Putting aside whether or not you can do shallow "checkouts" with Git, or how well it stores binary data, the fact is that it's designed to track lines of textual information floating around a tree of source code. As well as it does this, that model is not suited to tracking libraries of binary data.
Honestly though, that's about the only solid reason I would recommend it :P
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
