3 ms·

Subversion vs. Git: Myths and Facts

2 points by rusk 8y ago

seren 8y ago
While obviously biased, I have at least learned that svn seems to have easier merge experience than it used to.
jakear 8y ago
This is hardly an unbiased post... which is fine, people can write what they want to write, but it makes it easy to dismiss the entire article as simply being the work of an “svn fanboy”. It also has some inaccuracies: git can be extended to support large repositories; Microsoft has OS tooling that enables them to keep the entire Windows codebase in a single git repo, using a “copy-on-access” model, which seems to be equivalent to SVN’s offering. And things like git-lfs help with large binaries. As for the “larger teams” argument, if all you’re looking for is consistency of single files, SVN’s model seems to be equivalent to pulling before a push... which is what you do anyways (Maybe I’m missing something here?). As for the CLI, I consider that separate from the interesting discussion. There are good CLI wrappers for git (gitless, etc), and also GUI wrappers. I’m sure similar wrappers exist for SVN, but it’s besides the point.
java-man 8y ago
having worked with both svn and git (and cvs, perforce, teamware), and having integrated svn/git/cvs/perforce clients into a production application, I have to say that switching to git was the most enjoyable experience. yes, git commands have weird names. yes, git is puzzled by renames. yes, merging might be a problem. but svn is just too damn slow! svn is "cvs done right". there is no way to do a cvs right: file-oriented change control must be replaced by a snapshot-based change control (and it was, in git). now if I could only version directories and attributes in a platform-independent way...
- rusk 8y ago
  Sorry, I just can't let your second to last remark pass: SVN is snapshot based.
  - java-man 8y ago
    Until 1.7 (?) they used .svn/ in each directory. They since switched to a different storage arrangement. I don't know how good or bad it is now. Early on I've seen situations where the workspace got corrupted to the point where I needed to wipe it out and do a clean check out.
    - rusk 8y ago
      Yeah I don't know, I haven't used SVN in a while, but one thing I certainly did miss when moving to git is that SVN has a revision number for the entire repository [x], which was very handy for build identifiers and the like. [x] any change to any file or property increments the overall revision number so you can always retrieve the entire state of the repo at any particular point in time.
chmaynard 8y ago
This may be the first website I've seen that has absolutely no information about the identity of the writer or the purpose of the company behind the .com domain, assuming there is one. Strange.

2 points by rusk 8y ago

While obviously biased, I have at least learned that svn seems to have easier merge experience than it used to.

This is hardly an unbiased post... which is fine, people can write what they want to write, but it makes it easy to dismiss the entire article as simply being the work of an “svn fanboy”. It also has some inaccuracies: git can be extended to support large repositories; Microsoft has OS tooling that enables them to keep the entire Windows codebase in a single git repo, using a “copy-on-access” model, which seems to be equivalent to SVN’s offering. And things like git-lfs help with large binaries. As for the “larger teams” argument, if all you’re looking for is consistency of single files, SVN’s model seems to be equivalent to pulling before a push... which is what you do anyways (Maybe I’m missing something here?). As for the CLI, I consider that separate from the interesting discussion. There are good CLI wrappers for git (gitless, etc), and also GUI wrappers. I’m sure similar wrappers exist for SVN, but it’s besides the point.

java-man 8y ago

having worked with both svn and git (and cvs, perforce, teamware), and having integrated svn/git/cvs/perforce clients into a production application, I have to say that switching to git was the most enjoyable experience. yes, git commands have weird names. yes, git is puzzled by renames. yes, merging might be a problem. but svn is just too damn slow! svn is "cvs done right". there is no way to do a cvs right: file-oriented change control must be replaced by a snapshot-based change control (and it was, in git). now if I could only version directories and attributes in a platform-independent way...

rusk 8y ago
Sorry, I just can't let your second to last remark pass: SVN is snapshot based.
- java-man 8y ago
  Until 1.7 (?) they used .svn/ in each directory. They since switched to a different storage arrangement. I don't know how good or bad it is now. Early on I've seen situations where the workspace got corrupted to the point where I needed to wipe it out and do a clean check out.
  - rusk 8y ago
    Yeah I don't know, I haven't used SVN in a while, but one thing I certainly did miss when moving to git is that SVN has a revision number for the entire repository [x], which was very handy for build identifiers and the like. [x] any change to any file or property increments the overall revision number so you can always retrieve the entire state of the repo at any particular point in time.

chmaynard 8y ago

This may be the first website I've seen that has absolutely no information about the identity of the writer or the purpose of the company behind the .com domain, assuming there is one. Strange.