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

http://pedro.larroy.com/blog/?p=272

by jemeshsu • 15 years ago

27 24 15 years ago

pedro.larroy.com

zdw2• 15 years ago

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

kevingadd2• 15 years ago

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.

zdw2• 15 years ago

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.

ghurlman• 15 years ago

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

pnathan3• 15 years ago

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.

bostonvaulter2• 15 years ago

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

andrewcooke• 15 years ago

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

awt• 15 years ago

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.

pnathan3• 15 years ago

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.

rlpb• 15 years ago

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.

johnm• 15 years ago

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.

hunterp• 15 years ago

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

sathyabhat• 15 years ago

well, good for you then.

vijaydev• 15 years ago

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

parfamz• 15 years ago

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

wanderr• 15 years ago

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.

DrJ• 15 years ago

"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• 15 years ago

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.

alexandrul2• 15 years ago

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?

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

Related Stories