4 ms·

What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to

What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).

PretzelFisch 10y ago
You don't have much history in git at the moment.
- AbacusAvenger 10y ago
  Didn't he say he imported a repository with 25 years of history?
- drewg123 10y ago
  We have 25 years of history. The initial clone time for hg and git is within the same order of magnitude (order of an hour), though git manages to be about 50% faster at that too.
rjbwork 10y ago
Where were and are you hosting it? SSH vs HTTPS? Client? OS? Any hooks?
- drewg123 10y ago
  We were hosting both on an ESX VM and clones / pulls were done via SSH. OS was FreeBSD on both ends. Hookless. Part of the reason for the move is that we wanted to take advantage of the corp-wide infrastructure of an Atlassian stash server hosted in the cloud and professionally maintained, so as to get away from maintaining our own repo. But the speeds I quote above were for the initial phase of the conversion, when both repos ran on the same ESX VM and direct comparisons were meaningful. Now that its hosted professionally in the cloud, it seems even faster. Note that I'm across ~2500 miles of VPN from the home office, and that surely has something to do with it.
  - rjbwork 10y ago
    Interesting...I've noticed mercurial can be a little slow at times, but never had a problem with that much pull lag. Could be an overloaded server maybe? Or just outside the scope of my experience.
jgalt212 10y ago
> 25 years of history Why do you need to keep all 25 years of commits?
- mkj 10y ago
  Because it's useful to figure the intent of strange-looking code that was last touched 15 years ago. (Don't know the parent's situation, but that's the case for me here. Perforce isn't too bad for that)
  - jgalt212 10y ago
    I heard you. But for me, sometimes it's better just to start fresh than to try to figure out the intent of some ancient history. In this case, I guess that's BDD over TDD.
Mathiasdm 10y ago
What version of Mercurial were you using? Additionally, was your repository very branchy? Were your pulls stuck for a very long time on 'adding manifests'? It's possible that your slow pulls were due to the initial storage format being inefficient for very branchy repositories. I've documented migrating to generaldelta to solve this here: https://book.mercurial-scm.org/read/scaling.html#scaling-repositories-with-many-branches https://book.mercurial-scm.org/read/scaling.html#scaling-rep... Additionally, using the 'clonebundles' feature, it's possible to speed up your initial clone by a huge amount (making it way faster than non-clonebundles Mercurial or Git): https://book.mercurial-scm.org/read/scaling.html#improving-server-scalability-and-cloning-speed https://book.mercurial-scm.org/read/scaling.html#improving-s... Of course, this is too late for you, I guess...
marcinkuzminski 10y ago
That is not normal. We at RhodeCode works with some of biggest Mercurial behind-the-firewall setups. We have one customer which uses a global VPN for their few instances. They always measure Mercurial pull performance using a load tests. For example between 4.2.X and 4.4.X version of our software we went form 1.8s to 1.4s average time for a pull to happen under load. We only do this via HTTP since this can be really optimized for speed. So having to take minutes sounds like some backend problems like overloaded server, not enough workers to handle connection etc.

PretzelFisch 10y ago

You don't have much history in git at the moment.

AbacusAvenger 10y ago
Didn't he say he imported a repository with 25 years of history?
drewg123 10y ago
We have 25 years of history. The initial clone time for hg and git is within the same order of magnitude (order of an hour), though git manages to be about 50% faster at that too.

rjbwork 10y ago

Where were and are you hosting it? SSH vs HTTPS? Client? OS? Any hooks?

drewg123 10y ago
We were hosting both on an ESX VM and clones / pulls were done via SSH. OS was FreeBSD on both ends. Hookless. Part of the reason for the move is that we wanted to take advantage of the corp-wide infrastructure of an Atlassian stash server hosted in the cloud and professionally maintained, so as to get away from maintaining our own repo. But the speeds I quote above were for the initial phase of the conversion, when both repos ran on the same ESX VM and direct comparisons were meaningful. Now that its hosted professionally in the cloud, it seems even faster. Note that I'm across ~2500 miles of VPN from the home office, and that surely has something to do with it.
- rjbwork 10y ago
  Interesting...I've noticed mercurial can be a little slow at times, but never had a problem with that much pull lag. Could be an overloaded server maybe? Or just outside the scope of my experience.

jgalt212 10y ago

> 25 years of history Why do you need to keep all 25 years of commits?

mkj 10y ago
Because it's useful to figure the intent of strange-looking code that was last touched 15 years ago. (Don't know the parent's situation, but that's the case for me here. Perforce isn't too bad for that)
- jgalt212 10y ago
  I heard you. But for me, sometimes it's better just to start fresh than to try to figure out the intent of some ancient history. In this case, I guess that's BDD over TDD.

Mathiasdm 10y ago

What version of Mercurial were you using? Additionally, was your repository very branchy? Were your pulls stuck for a very long time on 'adding manifests'? It's possible that your slow pulls were due to the initial storage format being inefficient for very branchy repositories. I've documented migrating to generaldelta to solve this here: https://book.mercurial-scm.org/read/scaling.html#scaling-repositories-with-many-branches https://book.mercurial-scm.org/read/scaling.html#scaling-rep... Additionally, using the 'clonebundles' feature, it's possible to speed up your initial clone by a huge amount (making it way faster than non-clonebundles Mercurial or Git): https://book.mercurial-scm.org/read/scaling.html#improving-server-scalability-and-cloning-speed https://book.mercurial-scm.org/read/scaling.html#improving-s... Of course, this is too late for you, I guess...

marcinkuzminski 10y ago

That is not normal. We at RhodeCode works with some of biggest Mercurial behind-the-firewall setups. We have one customer which uses a global VPN for their few instances. They always measure Mercurial pull performance using a load tests. For example between 4.2.X and 4.4.X version of our software we went form 1.8s to 1.4s average time for a pull to happen under load. We only do this via HTTP since this can be really optimized for speed. So having to take minutes sounds like some backend problems like overloaded server, not enough workers to handle connection etc.