[Python-Dev] Mercurial migration readiness

Tres Seaver tseaver at palladion.com
Sat Jul 3 18:36:12 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin v. Löwis wrote:
> Am 02.07.2010 15:09, schrieb Fred Drake:
>> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> The two sets of repositories use different conversion tools and rules.
>>> They have nothing in common (different changeset IDs, different
>>> metadata, different branch/clone layout).
>> I'd love to see a more detailed description of this, including why
>> someone new to Mercurial would choose one over the other.
> 
> I think someone new to Mercurial shouldn't choose either one.
> 
> Just sit back and wait for the real migration to happen.

I would say that using the SVN mirror is a fine way to experiment with
using hg against the Python sources to develop and test patches.  Here
is the setup I have used for work against trunk (I have a parallel pair
of repositories for the release2.6-maint branch):

- - Create a "pristine" clone of the trunk (one where I never commit any
  changes):

  $ cd $python_repo
  $ hg clone http://code.python.org/hg/trunk/ pytrunk-upstream

- - Create a local clone from that repository:

  $ hg clone pytrunk-upstream pytrunk-work
  $ ./configure && make

Before working on a patch, I refresh the upstream repository:

  $ cd $python_repo/pytrunk-upstream && hg pull

and pull any changes into the local working repository:

  $ cd $python_repo/pytrunk-work
  $ hg pull -u
  $ make

I make a branch per roundup issue number in the working repository (in
order to avoid needing to rebuild the world for each issue):

  $ cd $python_repo/pytrunk-work
  $ hg branch  issue4265-shutil_copyfile

and then test / tweak the patch on that branch, committing as I go:

  $ patch -p0 < /tmp/shutil_copyfile.patch
  $ hg commit
  $ make
  $ ./python -E -tt -m test.regrtest test_shutil

etc.  If I have tweaked the patch, I can export a new version of the patch:

  $ hg log -p -b issue4265-shutil_copyfile > /tmp/updated_fix.patch

I haven't tried yet, but I imagine I could use 'hg email' to send the
patch as well.

Once the migration is done, of course, users who have been working with
that mirror will need to set up new clones for the upstream and re-clone
the working trees, as the revision IDs won't match, etc.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvZvgACgkQ+gerLs4ltQ71GACfTw4kNDm+IOv7Jvq8XFtCu6XD
rXoAn3G7i+emGwgp9bxhaHQ+gctIXilA
=am67
-----END PGP SIGNATURE-----



More information about the Python-Dev mailing list