Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :

...

In preparation for the hg switch, I would recommend that, if you have any feature branches managed with svnmerge, you sync them with the py3k branch before we switch. That way, it will make it easier to "bridge the gap" when you create a new repository for your work after the switch (the svnmerge information isn't retained in the converted repo).

Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)?

I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-featur... It doesn't cover importing work from SVN, but it should be as simple as "apply your current patch" where the text says "You can now work on your feature". A caveat of these instructions is that pushing a whole cpython-based repo will be quite slow unless you have a large upload bandwidth (most users have asymmetric connections). So we would like to offer a special command for committers to make a clone of a repository *from the server, to the server*. In my current prototype this is spelled as: ssh hg@hg.python.org clone <srcrepo> <dstrepo> for example: ssh hg@hg.python.org clone cpython features/pep-382 where "features/pep-382" will be a new repo on hg.python.org cloned from the cpython repo on hg.python.org. Meaning no heavy network transfer occurs. Then you clone the dest repo and the only changesets will have to push will be those representing your own work. If you think the "remote clone" trick above is good enough, I'll publicize it in the devguide. Regards Antoine.

On Mon, 28 Feb 2011 23:54:46 +0100 "Martin v. Löwis" wrote:

Am 28.02.2011 23:45, schrieb Antoine Pitrou:

...

Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :

...

...

In preparation for the hg switch, I would recommend that, if you have any feature branches managed with svnmerge, you sync them with the py3k branch before we switch. That way, it will make it easier to "bridge the gap" when you create a new repository for your work after the switch (the svnmerge information isn't retained in the converted repo).

Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)?

I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-featur...

It doesn't cover importing work from SVN

But that's what I was specifically asking about: if I svnmerge my feature branch now - what specifically do I gain? Why are you asking me to do that? Why does doing so make it easier to "bridge the gap"?

Because you don't have to find whichever faraway changeset on which to base your initial changes. You can just apply your patch on the latest "default" changeset in the Mercurial repository and, in all likelihood, you won't get any conflicts. Regards Antoine.

On 06.03.2011 12:56, Stefan Krah wrote:

Antoine Pitrou wrote:

...

...

Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)?

I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-featur...

First, thanks everyone for converting the active feature branches! - I've a couple of questions:

1) The default branch in the repository features/py3k-cdecimal contains all cdecimal changesets. I assume that the recommendation from the devguide to create a new named branch inside the new repository does not apply here, so I'll use 'default' for future cdecimal changes. Is this correct?

You can also start working on a named branch for easier switching. Just do a "hg branch cdecimal". This assumes that the branch history is not desired to be preserved when the branch is finished, and just a single patch is committed to the main repo.

2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion?

No; "inactive" simply means that the branch currently has no real head, since all heads have been merged into another branch. If all developers merge their changes promptly, it will be the default state of the maintenance branches except for 2.7. Georg

On Sun, Mar 6, 2011 at 10:17 PM, Georg Brandl wrote:

...

2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion?

Hmm, and legacy-trunk should already be closed actually.  It does not show up in "hg branches" for me.

I assume Stefan was referring to the features/py3k-cdecimal clone rather than the cpython one. This is going to happen with all the server-side clones - we really only want "default" in the clone, but the maintenance branches will come along for the ride. There are actually a few things related to server-side clone maintenance that I'm not entirely clear on: - is it OK to work on default, or does that cause problems with merging back later? - is there an easy way to close all the branches that aren't of any interest and avoid reopening them when merging from the cpython clone? - how do we track changes in cpython:default while continuing? By pulling from cpython into our local feature clone and pushing back to the server-side clone? Unrelated question: which is the "practice area"? Devguide says "test", but we also have "sandbox/cpython". Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

Georg Brandl wrote:

...

2) 3.2, 3.1 and legacy-trunk show up as 'inactive' on the command line, but not in the web interface. Should these be closed to avoid confusion?

Hmm, and legacy-trunk should already be closed actually. It does not show up in "hg branches" for me.

It does here after a fresh clone: $ hg clone http://hg.python.org/features/py3k-cdecimal/ ... $ hg branches default 47990:6a1c8fcce229 3.2 47988:a0752d92d207 (inactive) 3.1 47987:9e9aa450a5f8 (inactive) legacy-trunk 33482:cde58cd07e7d (inactive) Stefan Krah