[Python-Dev] Mercurial? (original) (raw)

Dirkjan Ochtman dirkjan at ochtman.nl
Sun Apr 5 17:47:12 CEST 2009

On 05/04/2009 17:18, Antoine Pitrou wrote:

It is a cheap price to pay if there is a significant return for it. In my experience using the hg mirror of the py3k branch, I don't remember having had to run "annotate" on the trunk to hunt for a change that I'd witnessed in py3k. Other developers may have different experiences, though.

As for the clone time, one of our proeminent developers is, IIRC, on a 40 kb/s line. Perhaps he wants to step in and say whether cloning the trunk is a painful experience for him, or not.

Sure it's painful, but he only has to go through that once, maybe twice.

The consensus seems to be that it will not happen before a couple of years.

See, I think the point here is that, even though you want the branches to be clones, you also want them to all be part of the same directed acyclic graph (that DAG thing I keep nattering on about). That way, you can later merge every branch back in to some other branch (even if it's trivial merge that doesn't keep anything from one of the branches). Even if that's not for a couple of years, it's nice when you'll be able to do it in a couple of years without changing all the hashes (meaning everybody has to re-clone).

For any dial-up providers, we could for example provide a repository that just has the changesets up to the split between trunk and py3k. He can clone that once, clone it locally, then pull the rest of the respective history in those local clones.

If you don't have common history, a few of the niceties of having a DAG-based DVCS in the first place go away; that seems like a pity.

Does the hg protocol compress that good? I would have thought there is already a lot of compression in the layout (given that it seems much more efficient than some of its competitors).

When used over HTTP, hg uses bundles (which can also be used as separate file to exchange changesets informally). Bundles contain gzip- or bzip2-compressed csets. When communicating over SSH, on the other hand, hg defaults to uncompressed streams, because the assumption is that connections can use SSH's compression, which is more efficient.

All of this functions on top of the already quite efficient revlogs that make up the basic storage model for hg.

Cheers,

Dirkjan

More information about the Python-Dev mailing list