Subject: Re: [boost] [git] Mercurial?
From: Christof Donat (cd_at_[hidden])
Date: 2012-03-21 05:21:11
> 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
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.
-- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk