[IPython-dev] What do we do about repository formats???
Fri Feb 12 03:31:57 CST 2010
On Thursday 11 February 2010 21:27:28 Ville M. Vainio wrote:
> [...] Not so with hg, people can basically use it
> after they understand dvcs in general.
> I also like the fact that it's trivial to put up a "hg serve" session
> for quick collaborative hacking, and that you get time based "simple"
> revision numbers instead of relying only on hashes.
OK, my 2 cents:
About 2 years ago, I made the choice myself. I went with hg, because I saw
the majority of (python) projects I watched making this choice. I did never
regret it, to the contrary. From the discussions on this list and on many
other OSS development lists, my impression is that
- bzr's strenth is launchpad, but it sometimes tries to be too clever and it's
behavior is not completely trivial to predict, while
- git is for professionals. Its UI is said to have improved, but still it
seems to be the swiss army knife which you need to know very well in order to
use the correct part of it.
hg's big strength is its simplicity, really. Out of the box (i.e. without any
third-party extensions), it is incredibly simple to use and understand. After
a while you start to become more brave and try out some extensions which offer
dangerous commands, but I have always stayed in harmony with mercurial.
The mercurial mailing list offers help for everyone, often discussing either
optimized ways to perform certain tasks, or general DVCS workflows, often with
posters trying to convince their bosses to make the switch from SVN or
(shudder) CVS. But I have never had the impression that there's anything hard
to understand with mercurial.
Oh, and BTW: the repository format is *incredibly* stable, with only one minor
(filename mangling) change in all the years. Basically, Matt chose the
correct design from the beginning.
I do not plan to convince anybody that hg is better than bzr, but I want to
report that I am very happy with it (and I am willing to answer hg-related
questions if you want more input).
More information about the IPython-dev