'Hot migrating' from SVN to mercurial, and why we choosed HG over GIT. | Hacker News Reader

'Hot migrating' from SVN to mercurial, and why we choosed HG over GIT.

pedro.larroy.com

27 pointsjemeshsu24 comments

TL;DR: They have windows developers, git isn't optimized for use on windows, whereas HG runs well wherever Python is available.

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.

Good to know.

I wish there was an up to date comparison of current code out there - most of the "git on windows has problems" anecdotes I'm aware of are from at least a year ago.

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

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.

I tried to use TortoiseGit. I found it a practically unusable GUI compared to TortoiseHG.

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-...

TortoiseHG's gui needs a designer. I have just about come to the conclusion it was made by someone who doesn't like HG as a joke. It doesn't use HG's terminology, it is fairly unintuitive.

This accords with my experience as well. I've found HG to be more intuitive to use: less immediately exposed commands, branches were 'obvious', and the help has been absolutely superb.

Further, it Just Works on OSX/Windows/Linux (providing the Python is compiled right...).

The big downside to hg IMO is its repository size as opposed to git. I keep a fair number of PDF documents in one repo, and a hg-git conversion drops the size by quite a lot.

What do you use to do the hg-git conversion?

I can't speak for pnathan, but I would assume he uses hg-fast-export.

...and he also appreciates the ease of use.

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.

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.

Additionally, in open source development, you don't submit your mess. You submit clean patchsets ready for review. I don't see why a private development tree should be any different.

There are multiple approaches to "rewriting history" in a dvcs depending on what your workflow and preferences are.

In Hg you can do various forms of rebasing and rewriting history, e.g.: * http://mercurial.selenic.com/wiki/ConcatenatingChangesets * http://mercurial.selenic.com/wiki/EditingHistory * http://mercurial.selenic.com/wiki/RebaseExtension

The difference between Hg and Git in this regard is much more a question of what's the basis of their philosophy. Git promotes rewriting & rebasing while Hg is biased towards a more conservative approach.

"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?

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.

Did you try altering web server heading settings? http://stackoverflow.com/questions/686217/maximum-on-http-he...

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

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.

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

well, good for you then.

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

thanks for the correction. I'm not a native english speaker.

Reply on news.ycombinator.com