
'Hot migrating' from SVN to mercurial, and why we choosed HG over GIT. - jemeshsu
http://pedro.larroy.com/blog/?p=272
======
zdw
TL;DR: They have windows developers, git isn't optimized for use on windows,
whereas HG runs well wherever Python is available.

~~~
kevingadd
How strange. In my experience TortoiseGit is far superior to TortoiseHG, and
as a result as a windows developer I always choose git instead of Mercurial.

~~~
ghurlman
Can you extrapolate? I've never liked Tortoise*, preferring to stick to the
command line - how is T-Git better?

~~~
kevingadd
TortoiseGit's UI is much better designed than TortoiseHG's - operations you
want to perform tend to be exposed in more obvious places, with clearer names
and simpler UIs. In many cases it offers commands that encapsulate a set of
underlying operations; for example, TortoiseGit offers subversion-style Commit
and Revert dialog boxes that behave like the equivalent dialog boxes in
TortoiseSvn, even though Git has no directly analogous commands. This is
really good if you want to get work done without being a Git expert.

In particular, Rebase in TortoiseGit has an excellent user interface that
takes Git's command line rebasing process and turns it into a user-friendly
graphical equivalent. I've yet to find any equivalently pleasant user
interfaces in TortoiseHG; pretty much all of TortoiseHG's user interfaces are
tangled messes of dropdown menus and checkboxes that try to reproduce every
mercurial configuration switch.

TortoiseGit is also faster and more stable than TortoiseHG. I'm not sure if
this is because TortoiseHG is largely written in Python+QT, or just because
TortoiseGit is more mature - I use TortoiseHG a lot at work when interacting
with mercurial repositories, and it crashes frequently, but I've never had
TortoiseGit crash or freeze on me.

There are also a lot of UX problems with TortoiseHG that seem to originate in
the design of Mercurial, though, so this may come down to my personal taste.

~~~
alexandrul
Given that both tools have their ups and downs, my reasons for picking
TortoiseHg for Windows development are listed on SO:
[http://stackoverflow.com/questions/2550091/best-support-
now-...](http://stackoverflow.com/questions/2550091/best-support-now-on-
windows-mercurial-or-git/2575991#2575991)

------
awt
_With mercurial I think is better to abandon the idea of rewriting history to
make it look nicer or more linear. The good point is that your history
reflects precisely what happened and how developers merged the code_

Rewriting history doesn't just make the git log look nicer. It gives you the
ability to more easily create atomic commits, and it ensures that commits in a
branch that is later merged back to master are contiguous instead of sprinkled
among all of the other commits from all other branches. If you are tracking
down a bug, this helps a lot, especially if you use git bisect.

~~~
pnathan
There are two different philosophies of branches as near as I can make out.

* Branches as 'records of effort'/'who did what when on what project'.

* Separating lines of development to keep mainline builds from falling over.

In a 'audit-thy-process' environment, immutable history and records of
projects have a high importance. If the goal is 'simply' to separate lines of
development - well then you can squash commits and it doesn't matter.

------
DrJ
_"I understand how it works internally but I have trouble remembering the
unnecesary complex command to do simple tasks"_

I would like to know more which commands these are. Is there something other
than push, pull, commit, add, branch, checkout for 'simple' tasks? Or are we
talking about syntaxes for setting up like init or doing origin-master stuff?

------
garibaldi
I work for a company which uses hg exclusively. I think it's a great version
control system, but it suffers from an annoying implementation problem which
gets in the way of our workflow.

When an hg pull is performed the pulling repository must let the other repo
know about the state of each of it's branches. This includes closed branches.

In addition, hg uses HTTP as it's network protocol. I think it transmits it's
branch info as part of the headers in a GET request. The result is that once
you have a certain number of branches in your repo the pulls fail because
there isn't enough room in the headers to transmit the state of the repo.

We are heavy users of branches for features/bugfixes as this helps us to
improve quality control. This hg shortfall means we have to rethink our souce
control procedures, we only learned about this problem when we encountered it
- several thousand changesets into using hg. Apparently a fix is several
months away from being in an hg release.

hg is great, but the above problem + the mutable changesets offered by git now
has me leaning more towards the git camp.

~~~
alexandrul
Did you try altering web server heading settings?
[http://stackoverflow.com/questions/686217/maximum-on-http-
he...](http://stackoverflow.com/questions/686217/maximum-on-http-header-
values)

Just curious, how many branches do you have in the repository?

------
wanderr
My experience with git in windows has been great. It just works, and is no
slower than Linux machines. I use msysgit and tortoisegit on large and complex
projects, with no issues.

------
hunterp
"Choosed" Seriously? I "choosed" to not read this article.

~~~
vijaydev
Please be nice when pointing out mistakes. Not everyone is a native English
speaker here.

