On 06.03.2011 16:44, skip@pobox.com wrote:

Georg> Yesterday's repository was still the test repository, now it's Georg> the real one. You'll need to clone again.

Thanks.

I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches:

hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7

If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive?

If you don't change repo configuration after these commands, "hg pull" in the 3.2 repo will pull from the local cpython repo. I'd advise to set the "default" entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://hg@hg.python.org/cpython BTW). This way, "hg push" and "hg pull" communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, "hg push ../3.2". (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names). Georg

On 06.03.2011 17:15, Nick Coghlan wrote:

On Mon, Mar 7, 2011 at 2:07 AM, Georg Brandl wrote:

...

If you don't change repo configuration after these commands, "hg pull" in the 3.2 repo will pull from the local cpython repo. I'd advise to set the "default" entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://hg@hg.python.org/cpython BTW).

This way, "hg push" and "hg pull" communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, "hg push ../3.2". (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names).

Given the recommended workflow in the devguide (i.e. when forward porting bug fixes, update all public branches in a single push), keeping the transitive connections between local clones is probably a good idea. It also means that we can do the full porting workflow even when offline.

Sure, it's anyone's choice. I wouldn't go so far as to call this a "connection". It is really important for everyone to understand that every clone is a standalone entity, and the *only* thing that makes up this "connection" is the single entry "default = ..." in the repo's .hg/hgrc. Georg

On 06.03.2011 18:45, skip@pobox.com wrote:

Nick> Given the recommended workflow in the devguide (i.e. when forward Nick> porting bug fixes, update all public branches in a single push), Nick> keeping the transitive connections between local clones is Nick> probably a good idea. It also means that we can do the full Nick> porting workflow even when offline.

So, when I cloned, I should have done something like this:

hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4

instead of cloning everything from cpython, right?

You can still change the "default" entries in .hg/hgrc to point to your desired default location. That's the *only* thing that changes depending on where you clone from. Georg

On 2011-03-06 20:09, "Martin v. Löwis" wrote:

...

...

So, when I cloned, I should have done something like this:

hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4

instead of cloning everything from cpython, right?

You can still change the "default" entries in .hg/hgrc to point to your desired default location. That's the *only* thing that changes depending on where you clone from.

What I often do is to add another line (below default=, or in ~/.hgrc), so I can do

hg pull # pulls from my local copy hg push pydotorg # pushes directly into the remote directory

Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name "default-push" with special meaning: 'hg push' pushes to (1) the path defined as default-push under [paths] in .hg/hgrc (2) if default-push is not defined, to the default path (3) if neither is defined, the command aborts with an error message 'hg pull' always pulls from the default path (default-push doesn't matter for pull). (Same for the outgoing/incoming commands.) http://selenic.com/repo/hg/help/paths

On Mon, Mar 7, 2011 at 5:36 AM, Adrian Buehlmann wrote:

Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name "default-push" with special meaning:

'hg push' pushes to

(1) the path defined as default-push under [paths] in .hg/hgrc (2) if default-push is not defined, to the default path (3) if neither is defined, the command aborts with an error message

'hg pull' always pulls from the default path (default-push doesn't matter for pull).

Oh, so I can split the lookup so a bare "hg pull" comes directly from pydotorg, while having a bare "hg push" follow the transitive links between my local clones? Very interesting! I'll try the fully transitive workflow for now, though and see how I like it. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 3/6/2011 11:07 AM, Georg Brandl wrote:

On 06.03.2011 16:44, skip@pobox.com wrote:

...

Georg> Yesterday's repository was still the test repository, now it's Georg> the real one. You'll need to clone again.

Thanks.

I have a question about updates from cloned clones. Suppose I clone the central repo then clone locally to get the 2.7 and 3.2 release branches:

hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone cpython 2.7

If I want to later update my maintenance branches to get any updates will it suffice to just hg pull in my 2.7 and/or 3.2 directories or do I need to pull in cpython first? I guess my question is, are these clones transitive?

If you don't change repo configuration after these commands, "hg pull" in the 3.2 repo will pull from the local cpython repo. I'd advise to set the "default" entry in each of the clones' .hg/hgrc file to http://hg.python.org/cpython (as a committer you should be using ssh://hg@hg.python.org/cpython BTW).

But would it work to just pull once into default from the central repository (slow) and then pull from there (fast) into maintenance clones? I expect to nearly always be only working on issues that affect default.

This way, "hg push" and "hg pull" communicate with the remote repo. You can still exchange commits with the other local clones by using, for example, "hg push ../3.2". (You can also add another entry in the .hgrc's [paths] section if you want to give nicknames to these path names).

Georg

-- Terry Jan Reedy

On 3/7/2011 2:16 AM, Georg Brandl wrote:

On 07.03.2011 00:16, Terry Reedy wrote:

...

But would it work

?? to just pull once into default from the central

...

repository (slow) and then pull from there (fast) into maintenance clones? I expect to nearly always be only working on issues that affect default.

Pulling just a few changes into local clones from remote should always be fast.

On my current older WinXP machine, the startup time to do anything with the svn repository was about 10 secs. Long enough to be a drag, not long enough to do much else ;-). Maybe it will be faster with *nix or newer Windows, hg, and newer machine (all of which I plan to get). -- Terry Jan Reedy

Nick> Transitive. This is nice for the patch flow (fix in oldest, push, Nick> switch to next, merge, commit and push, etc, then only touch the Nick> central server for the final push of all branches), but it does Nick> you mean you need to follow the reverse order when grabbing Nick> changes from the central repository. Ummm, push from where to where? Are you assuming some relationship between my sandboxes? "push" sounds to me like pushing my changes to the central repository. That's not what I would want to do. I should also point out for those not familiar with my past experiences with Mercurial, I gave up on it once before (pylockfile) because I got things so totally f**ked up. I went back to Subversion on Google Code and have been happy ever since. I approach this new way of managing Python development with a great deal of trepidation. Skip