Hi,
I have never heard a single technical argument, in all the endless mentions of Git among the people riding that bandwagon, why Git is better than SVN, or even why any DVCS is better than a centralized SCCS.
OK, I've been using rcs, cvs, vss, svn, mercurial and git. all except vss where a real step forward at their time. - rcs simply gave me the ability to track changes for myself - I don't remember the time before rcs, because I was too young then. I committed often, because it was rather cheep to do so and the first time I needed to revert a change (which happened to me more often those times than now, but it is still not over yet), I really began to love it. - cvs gave me the ability not only to track my own changes, but also collaborate with others who even worked on other computers. When the repository was local, I committed more often than when teh repository was remote. Working remote worked well, but slower. So an update or commit was more expensive. That also was the time, when I learned the term "merging hell". Everybody said, you should commit as often as possible, but noone did as often as with rcs. - let's not talk about vss, I don't find enough friendly words for it. The best about it is, that as far as I can see noone uses it any more. - with the time I of course also noticed the glitches in cvs, like e.g. untracked directories and the fact that it gets slower with an increasing history - just like rcs, etc. That was when svn kicked in. It solved quite some of those problems and I really thought, this was cvs done right. Actually svn still is the best central VCS that I have seen. Then some people told me about DVCS and I thought - hey, I am always online, when I work, so what the heck shall I do with that. I though SVN did the job well, which actually was true. Then this Submarine project came along. One of the managers in the company I then was working in became adventurous and asked us to try to write a new software to replace the existing one. We did not have a svn and not even a spare server, where we could have installed svn. So we simply took the first DVCS that came along. That was mercurial. I did not want to go back to svn afterwards, because mercurial lets me almost work as efficient as with rcs, but with all the advantages of collaboration. We did not need a central server, because as a team of two we could exchange changes directly. The collegue I was working together with, actually wanted back to svn, because he was using eclipse and he found, that the mercurial plugin for eclipse was in a very unstable state at that time. We were not able to explore all the features of mercurial, before the project became an official one and we switched back to the companies central svn. With git I have worked mostly at home for my own projects. It gives me all the advantages I have learned from mercurial. For an additional backup I simply push to another machine. I clone locally to experiment without cluttering my main repository with hundrets of old branches. I commit often, I experiment a lot. And I can do all of that on the train, at my parents, when taking a break from hiking up in the swiss mountains, etc. So I also niticed, that for private projects I am not always online. There was also a project where we planed to use git professionally - mercurial would also have been OK, but there was more git experience in the team. We tried to establish a branch based development process. What the business guys see as a "change" usually is an eventually quite huge set of changes to the developer. So every business change would become a branch. Whenever a change would have been mature enough, we would have merged it with the next release branch and rebase all the others that were still in work. For the next release we only had to take the current state of the next release branch. That project stayed with the companies central svn due to a management decission and the branch based development process never made it into production though we have shown the whole process to work. Theoretically you can do the same with svn as well and I have seen something similar based on cvs (that information actually was the input that made us think about it). The bad side is, that both of them are not really the big kings, when it comes to merging. Especially the ability to rebase a branch with git makes this aproach very comfortable and helps a lot to prevend to be trapped into merging hell. Now, those are more organizational advantages of DVCS, not technical ones. One techincal advantage I noticed with git over svn (I don't remember if mercurial has that as well) is that it also tracks merges. So I can see in the history, that a specific branch has already been merged with another one. With that branch based development proces I have described above, this feature is very usefull. In the end, when you ask me. I could live with svn, but I'd prefer a DVCS. Which one I don't care. I have a bit more experience with git, but that is not an issue. I'd also learn to use bazaar, monotone, et al. Christof -- okunah gmbh Software nach Maß Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055