RetroSearch Browse

Sun Jul 4 00:59:58 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-July/101419.html

> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)

In addition to the answer you got: this way of working is also the
process that I arrived at, independently.

I see two uses, both based around the problem "creating a full clone
will take a long time - much longer than a subversion checkout".
1. if I want several local checkouts (e.g. for testing separate
   features), I can clone them all from the local copy (thereby
   also preserving space, compared to independent clones)
2, throwing away local changes is not that easy in Mercurial,
   if you have committed them already. There are extensions to
   uncommit, but they are discouraged and have limitations. So it's
   best to throw away everything and start over fresh, which is
   faster if you have a pristine clone.

In either case, you keep pulling into the pristine clone from
python.org, and then uppdate your local clones as you please.

When pushing changes, it is best to directly push into the network
(rather than going through the pristine clone): if pushing fails due
to concurrent updates, you haven't cluttered your pristine copy.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-July/101419.html below:

[Python-Dev] Mercurial migration readiness