Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Christof Donat (cd_at_[hidden])
Date: 2012-03-21 05:21:11

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_at_[hidden]
                                      Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055