3 ms·
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 s
by 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 agoSorry, I just can't let your second to last remark pass: SVN is snapshot based.
- java-man 8y agoUntil 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 agoYeah 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.