
Mercurial 1.0 released - iamelgringo
http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew
======
hbien
I've been using Mercurial for personal projects and I've really been liking
it. I do a lot more branching and merging with it and it feels faster because
of local commits.

~~~
jmtulloss
I've noticed it feels faster than SVN even when used like svn (pushing/pulling
from a remote source)

------
nickb
We looked at few solutions at our startup and we decided to go with git
instead of Hg after we launch (we'll use svn until then). I actually liked
both and liked Hg a bit more due to its simplicity but since the Rails world
has adopted git and everyone's distributing code using git and github, the
decision was basically made for us.

~~~
SwellJoe
We're in the same boat. We've been using Subversion, but will switch to git
once our tools support it (we eat our own dog food, and Subversion is the only
revision control system our products support right now). The determining
factor for us was similar, as well...the Perl core developers appear to be
moving to git for all Perl development. We're a mostly Perl shop, so we'll go
where Larry and Co. goes. It just insures that the tool-chain for working with
our codebase with git will be really solid, if the majority of Perl developers
are also using it.

~~~
gcv
You know about the git svn bridge, right? It comes right in the standard git
distribution, works intuitively and easily, and is the only thing keeping me
sane as I work on two projects managed in Subversion. Basically, I use git in
my development environment, with all the slick branching, merging, and great
performance. Then I push code out to Subversion, and it all just works.

------
maximilian
It seems as though Linus (he wrote git right?) has successfully performed his
coup of the version control systems. Ok, not really, but its surprising that
he could change what was thought to be an essentially solved problem with cvs
and then svn. I would have never thought that someone could come up with a
better CVS, but then SVN came out. Then came Git, and then this. Just goes to
show that even problems that seem "solved" might have better solutions given a
different set of situations.

~~~
icky
> Then came Git, and then this.

Git and hg were both started in April, 2005, in response to the Bitkeeper
fiasco.

~~~
maximilian
Ahh... I knew Git was basically started with that Bitkeeper war, but since I
don't really follow linux politics much as I don't use it all that often, I
didn't realize that hg was started then as well. They seem very similar in
their paradigm shift away from the central repository style of CVS and SVN. Is
that a coincidence or was Bitkeeper also in this everything is a branch
method?

~~~
icky
I think it was Bitkeeper's solid decentralized workflow that convinced Linus
that VC would even be feasible for kernel development; hg and git were written
after people realized that they could no longer do without the features that
Bitkeeper had.

------
gregwebs
I haven't used Mercurial, but I highly recommend darcs over git. The only
advantage git has (which may be important to you) is it is much faster.
Interactive recording on darcs is a joy to use.

~~~
ltratt
darcs user interface is a joy to behold - it's far easier to get up and
running than git, and easier on a day-to-day basis. However even on a one man
project, I found that darcs performance problems started to bite after a few
hundred check-ins (darcs unrecord being an obvious problem). IMHO this isn't a
rare problem with darcs - any reasonably sized project is likely to hit this
at some point. I also managed to get my darcs repositories into an unusable
state several times just by pushing cherry-picked patches between them, which
wasn't fun.

I miss darcs in some ways, particularly as getting running with git is a pain
in the rear end. Fortunately darcs-git
[http://ftp.frugalware.org/pub/other/pacman-tools/pacman-
tool...](http://ftp.frugalware.org/pub/other/pacman-tools/pacman-tools/)
emulates enough of darcs user interface to sweeten the pill, and is definitely
a good way to get started with git. I've also found that some of the
functionality available in git but not in darcs has been very useful (even if
it is typically a pain to work out how to use it).

~~~
gregwebs
any more info on using darcs-git? Looks like a python script that implements
darcs user interface functionality on top of git without any need for darcs.

------
mronge
Mercurial rocks. We use it at the startup I work for, and it has been
invaluable. Being able to swiftly and easily make your own branches is
fantastic for prototyping.

~~~
jamesbritt
I'm an hg fan, too.

I pondered darcs, since there are a number of Ruby projects using it, but
landed on mercurial.

------
almost
I'm currently considering switching from Darcs to Mercurial or possibly Git.
I've had problems with Darcs taking vast amounts of time to commit larger
files and I'm assuming that both Merurial and Git (especially) will be much
better at that.

I'm leaning more towards Mercurial at the moment because while I don't use
Windows much myself I do want to be able to work with people who do.

Any thoughts would be appreciated....

~~~
gcv
Both git and hg are very nice, you will not go wrong with either one. If
Windows support in the near future is a priority, you should probably use
Mercurial. It works well today. The Windows port of git is coming along, but I
don't know how long it'll take to reach first-class citizen status.

That said, if you don't need to deal with Windows, I suggest using git. It has
a more power-user feel to it than Mercurial, and it has a few spectacular
features I can't live without: rebase, stash, and the git-svn bridge. I'm also
rather fond of git's lightweight branch mechanism. I know hg supports a
variant of rebase and stash using the Transplant and Queues extensions, but
the last time I looked at hg svn, it wasn't ready for use.

Also, when you read about git, you'll hear a lot of first-time users
complaining about "the index." Just remember to think of it as a staging area
for commits, and you'll be fine. It was a bit confusing at first, but then I
realized that I like using it for making granular commits and diff checking.

