From Git SCM Wiki
Jump to: navigation, search

As a full Git clone is often smaller than a full checkout, Git working directories (including the repositories) are typically smaller than the corresponding SVN working directories. There are even ways in Git to share one repository across many working directories, but in contrast to SVN, this requires the working directories to be colocated. it is not clear here which system requires colocated working directories. I assume it is Subversion but this sentence says its git?

It's Git. Git "colocated" working directories appears to refer to having the directories located on the same file system. However, I don't think it actually means working directories, but rather repository clones, which can be made using hard links, sparse mode and such, thus using less disk space. I don't see how you can have more than one working directory for a single Git repository (using, for instance GIT_WORKING_DIR or --work-tree) because the index is shared. The script git-new-workdir handles this though by creating a new .git directory and symlinking most files.

Subversion can be used with binary files (it is automatically detected; if that detection fails, you have to mark the file binary yourself). Just like Git.

Only that with Git, the default is to interpret the files as binary to begin with. If you _have_ to have CR+LF line endings (even though most modern programs grok the saner LF-only line endings just fine), you have to tell Git so. Git will then autodetect if a file is text (just like Subversion), and act accordingly. Analogous to Subversion, you can correct an erroneous autodetection by setting a git attribute.

I'm not sure why this point is here ; both git and svn process content verbatim by default. Neither git or svn will munge line-endings unless you ask them to. svn appears to have one more option for munging (CR), which won't be used often. The chief difference is that git supports path-globbing for attributes, whereas on svn they must be applied on a per-file basis, necessarily so because svn supports checkout of subtrees so you could be decapitating your attribute metadata. Otherwise, on the matter of "not screwing up your files by making assumptions about the content", they seem equal.

Actually the text suggests, that subversion would munge line-endings if the auto-detection fails to detect a binary file. This is wrong. The auto-detection of subversion only affects the mime-type attribute, which in turn only affects whether textual diffs are allowed or not. It does not affect the behaviour converting line-endings. This is very kind of confusing for people who have used systems like CVS, where a the binary flag of a file affects both: whether a textual diff is possible and whether line endings are converted.

Marking a file with the correct mime-type is important when you do things like surf your repository with a browser (esp. for web content, a browser that respects the mime-type (IE, not IE) will by default, display all HTML as plaintext from mod_dav_svn). svn mime-type autodetection (a subset of the auto-props feature) can be configured to specify a mime-type based on filename extension, as well as the default basic detection of application/octet-stream. You could happily do this with attribute globs on git, if I read the manual right, setting the crlf attribute. One big difference I do see is that if you turn on core.autocrlf, if a file is falsely determined to be text, it will get munged for line endings. On svn you must identify each file that you want line endings munged for manually (or via a manually configured feature).

All in all, yes, git has a slightly more convenient properties feature, but scoring for or against either product on these points is marginal ; both deal with binary and text properly, both have metadata features, both let you control EOL munging in an equivalent way. I would be shy about turning on autocrlf globally for git, simply because I don't think it's necessary for the majority of projects.

With Subversion, you can check out just a subdirectory of a repository. This is not possible with Git. For a large project, this means that you always have to download the whole repository, even if you only need the current version of some sub-directory. In times where fast Internet connections are only available in most cities and traffic over mobile internet connections is expensive, git can cost much more time and money in rural areas or with mobile devices. This is arguably mitigated by the small size of git repositories.

Note: I believe this can be done with "git checkout commit -- path"

Note: I think the author of the above note might be misinterpreting SVN's benefit here because of the difference in terminology. If this section was originally written by a SVN user, the equivalent in Git terminology would be that Git doesn't allow you to clone just part of a repository. After all, git checkout operates on some working copy; I tried a couple different versions of that command, and just get fatal: Not a git repository. Furthermore, this point is supported by The Git Community Book, which says "Git does not allow partial checkouts".

Merging in Git does not require you to remember the revision you merged from

Considering that Subversion 1.5 was release over 2 years ago, this point seems completely irrelevant.

It's impossible to see only merge related changes

This is demonstrably not true. A user can perform an `svn diff` against two repo URLs (or revisions) and clearly see the changes before merging. The same can be used against the local copy after having merged but before committing.

Pointing out mistakes

The page states that "it tries to provide a fair and unbiased comparison of Git and Subversion". It does not, because it spreads myths about Subversion and ignores the facts.

Here are some of the main mistakes made on the page:

Git's repositories are much smaller than Subversions (for the Mozilla project, 30x smaller)

This shouldn't be true. Most likely the Mozilla repository was significantly cropped during the migration from Subversion to Git.

Repositories size is practically the same if you compare Subversion repository size with Git repository. For example, WordPress codebase repository is 186MB in Subversion (35599 revisions) and 169 MB in Git (32647 revisions). Here is the benchmark.

Moreover, Subversion working copy is going to be much less in size, if compared to a Git clone. With Subversion, it's possible to check out just a subdirectory of the repository, while with Git each user have to download all 169 MBytes at once.

Git branches are simpler and less resource heavy than Subversion's

No, this is not true. Creating a branch in WordPress repository takes 1419 bytes in Git and just 1945 bytes in Subversion (here is the benchmark). Both are less than 2 KB, so you cannot say that Subversion's branches are somehow resource heavy.

Git was designed to be fully distributed from the start, allowing each developer to have full local control

This doesn't sound like a benefit. DVCS is just another approach to version control and it has its compelling cons such as missing granular access control and no support for exclusive locking. Locking and access control are very important for some users and hence Git is not suitable for them.

Git branches carry their entire history

What is this point about? Subversion branches carry their entire history too.

I think the page should be rewritten in a truly unbiased form. Git is a great version control system and Subversion has its problems, of course. But not as much as the page currently says. Claims like that branches are heavy in Subversion or that repository sizes differ in an order of magnitude are just fooling the readers.

--PavelLyalyakin (talk) 19:56, 22 December 2015 (UTC)

Personal tools