Please sync your feature branches

Hello, 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). For the record, and as mentioned in the updated PEP 385, we plan to do the final conversion on the 5th (that is next Saturday). Regards Antoine.

Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :
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" <martin@v.loewis.de> wrote:
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.

Antoine Pitrou <solipsis@pitrou.net> wrote:
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? 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? Stefan Krah

On 06.03.2011 12:56, Stefan Krah wrote:
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 <g.brandl@gmx.net> wrote:
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

Hi,
It's ok.
- 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?
You could do that (see "hg help commit" for the "--close-branch" option), but it can create new heads if you pull further changes on these branches when pulling from the cpython clone. So it's more annoyance than needed IMO.
Yes.
Unrelated question: which is the "practice area"? Devguide says "test", but we also have "sandbox/cpython".
The devguide should probably be updated to mention "sandbox/cpython". (that's a good practice item) Regards Antoine.

Georg Brandl <g.brandl@gmx.net> wrote:
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

On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah <stefan-usenet@bytereef.org> wrote:
It does here after a fresh clone:
Thats because it never got the revision that closed that branch, just merge http://hg.python.org/cpython/rev/b77918288f7d to http://hg.python.org/features/py3k-cdecimal/

Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :
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" <martin@v.loewis.de> wrote:
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.

Antoine Pitrou <solipsis@pitrou.net> wrote:
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? 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? Stefan Krah

On 06.03.2011 12:56, Stefan Krah wrote:
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 <g.brandl@gmx.net> wrote:
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

Hi,
It's ok.
- 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?
You could do that (see "hg help commit" for the "--close-branch" option), but it can create new heads if you pull further changes on these branches when pulling from the cpython clone. So it's more annoyance than needed IMO.
Yes.
Unrelated question: which is the "practice area"? Devguide says "test", but we also have "sandbox/cpython".
The devguide should probably be updated to mention "sandbox/cpython". (that's a good practice item) Regards Antoine.

Georg Brandl <g.brandl@gmx.net> wrote:
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

On Sun, Mar 6, 2011 at 7:52 AM, Stefan Krah <stefan-usenet@bytereef.org> wrote:
It does here after a fresh clone:
Thats because it never got the revision that closed that branch, just merge http://hg.python.org/cpython/rev/b77918288f7d to http://hg.python.org/features/py3k-cdecimal/
participants (6)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Dj Gilcrease
-
Georg Brandl
-
Nick Coghlan
-
Stefan Krah