|
While I can understand how git is better for the majority of use-cases, I found that it was far less suitable than SVN for what I want to do. I used git for a while (3-6 months) and then switched BACK to using SVN. It's true I didn't experience pain until I started using git. That's when the pain started. First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic. Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus. For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers. |
(If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.)
Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.