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). Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit. You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").Īlso, the tooling is still insufficient, at least on Windows. Two modes of creating repositories, checkout vs. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").Īs said above: Git adds complexity. With Git, that's the default mode anyway. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. Git REALLY shines when you are decentralized. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches. There are reasons for this, but it adds complexity. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters -bare and -shared which seems to be the "proper" way to set up a centralized repository. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.įirst of all, Git can be really confusing at first when working decentralized. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.Įdit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better. Git seems to be the "new, shiny, cool" thing. This looks good at first, but just keep in mind the added complexity to this approach. When you regain connectivity to the main repository, you can commit against it. Your local copy is a repository, and you can commit to it and get all benefits of source control. If you want to make a copy of your code, you have to literally copy/paste it. With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours. The key difference is that it is decentralized.
0 Comments
Leave a Reply. |