Mercurial migration readiness (was: Taking over the Mercurial Migration)
After reading PEP 384 and PEP 385 (finally) I got a strong impression that they are not ready for the change (read below the line for details), because they do not propose any workflow. So, instead of rushing with migration I'd like to propose incremental change rather than revolutionary that will allow people to taste what it like to work with Mercurial and update all relevant papers on the website. I propose to setup workflow that will include pulling changes to Mercurial master clone from current Subversion repository and pushing them back to Subversion using Mercurial. This will be similar to http://mercurial.selenic.com/wiki/DeveloperRepos scheme, but with hg-stable replaced with svn. I am willing to collaborate for getting this system in place before EuroPython even if I won't find a chance to get there. --- the line --- I didn' t have time to follow Mercurial discussion, so I expected PEP 384 and PEP 385 to be exhaustive reference on both the migration and workflow before and after the switch. Unfortunately, both are too vague in this respect and my opinion that migration now will do more harm than good. Primary concern is that will happen with central Subversion repository. There are a plenty of private tools and automated scripts that were written to work with central Subversion repository, so it is important that central Subversion repository continue to operate and be synchronized. However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching. The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python. In Subversion I do shallow checkouts of interesting features when I run into one bug or another. Not all patches are ready, so they stay in those checkouts as uncommitted diffs. To be prepared for conflicts I review code with `svn log -vr base:head` before updating. But with Mercurial I see two major problems with my workflow (which I am unlikely to change for the next few weeks due to heavy automation): 1. No shallow checkouts - that means that I have to copy 200Mb+ for every patch I have 2. No `hg log` command to see changes in my branch from remote repository before fetching them (I used to invoke `hg incoming`, but ended up with fetching everything with `hg pull` and then using `hg log -vr .:tip`, because `hg inc` didn't show changes that were already pulled, but not updated in wc, and `hg log` could not show incoming) 3. There is no clear branch separation in my working copy. I don't know how to diff files in different branches without copying 200Mb+ clone. I don't know how to diff my files with remote repository without pulling it. 4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain. So from these PEPs I can't really see how Mercurial solves problems with development. I can feel that it doesn't solve my problems, but I see no way where I can submit my user story. I would put accent on keeping mirror of Subversion as easy way to contribute for those who are not yet ready for DVCS. Subversion also provides greater interoperability. Assuming that any modern DVCS tool may act as Subversion client, we will gain more contributors if we won't try to force people use Python and Mercurial. [1] http://www.python.org/dev/peps/pep-0385/#the-future-of-subversion -- anatoly t.
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik <techtonik@gmail.com> wrote:
Primary concern is that will happen with central Subversion repository. There are a plenty of private tools and automated scripts that were written to work with central Subversion repository, so it is important that central Subversion repository continue to operate and be synchronized.
However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching.
It would certainly be possible to have snapshots of the hg repo be committed into SVN, but I think people will actually notice sooner that it's dead if we don't update it at all anymore.
The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python.
Mercurial is relatively flexible in that there are lots of ways you can do this, and so I find that, certainly for the local parts of the workflow (e.g. those that don't directly affect the repo that everyone sees), I don't want to mandate a certain workflow. On the other hand, there will certainly be documentation on a very basic workflow to get people started. Inevitably, in order to get the most out of the tool, people will have to investigate some different ways of doing things (e.g., mq, which is one of my favorite workflows -- I'd probably include a basic description of it in the docs for python-dev). Cheers, Dirkjan
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik <techtonik@gmail.com>wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python-dev archives but was unable to find much. Anyway... assuming there's a at least a clone of the central repository on one of those sites, you can fork it and work on your patch there. A core developer can then pull your patch to their local repository, tweak it as needed, then commit it to the central repository.
I would put accent on keeping mirror of Subversion as easy way to contribute for those who are not yet ready for DVCS. Subversion also provides greater interoperability. Assuming that any modern DVCS tool may act as Subversion client, we will gain more contributors if we won't try to force people use Python and Mercurial.
The hg-git tool allows Mercurial and git to interoperate, so that's not as much of an issue as it once was. It's geared toward using a Mercurial client to talk to a git server, but I'm told it can work the other way around with a bit of work. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik <techtonik@gmail.com> wrote:
Primary concern is that will happen with central Subversion repository. There are a plenty of private tools and automated scripts that were written to work with central Subversion repository, so it is important that central Subversion repository continue to operate and be synchronized.
However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching.
It would certainly be possible to have snapshots of the hg repo be committed into SVN, but I think people will actually notice sooner that it's dead if we don't update it at all anymore.
I remember the decision as being that SVN would be read-only after the switch. Which will cause some pain, yes, but probably not as much pain as trying to keep both workflows available would.
The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python.
Mercurial is relatively flexible in that there are lots of ways you can do this, and so I find that, certainly for the local parts of the workflow (e.g. those that don't directly affect the repo that everyone sees), I don't want to mandate a certain workflow. On the other hand,
And this is the reason that Martin says that a *working* (final configuration) repo must be available for some time before the transition takes place, so that we can all experiment and figure out what external workflow is needed, and document what people find to be useful internal workflows. I think someone needs to say, "OK, what's up is how it is going to be, you've got X weeks to make sure you can work with it and then we cut over" before the balance of the dev community is going to actually try working with it. But one or more volunteers could make the first cut at the workflow docs right now, I would think, and that would be a big help for this process I know I would have preferred to have such docs before I gave it a try...but I need to be able to talk intelligently about HG at PyOhio, so I need to start learning it this week. -- R. David Murray www.bitdance.com
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
The hg-git tool allows Mercurial and git to interoperate, so that's not as much of an issue as it once was. It's geared toward using a Mercurial client to talk to a git server, but I'm told it can work the other way around with a bit of work.
There's also heechee, which could be interesting for those who really love SVN. http://bitbucket.org/andrewgodwin/heechee Cheers, Dirkjan
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach <daniel@stutzbachenterprises.com> wrote:
Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python-dev archives but was unable to find much. Anyway... assuming there's a at least a clone of the central repository on one of those sites, you can fork it and work on your patch there. A core developer can then pull your patch to their local repository, tweak it as needed, then commit it to the central repository.
I'm pretty sure bitbucket will do a mirror once hg is up and running. Cheers, Dirkjan
On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik <techtonik@gmail.com>wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python-dev archives but was unable to find much.
We discussed this briefly at the Python language summit at PyCon '10, the discussion intersected and/or merged with the whole infrastructure discussion, got borg-ified by that, and I think discussions continue(d) on pydotorg-www in general. Personally I think it makes a great deal of sense to pay someone to manage this for us, but there were concerns about customizability and control that warrant further investigation. Since it's DVCS, it's much easier to change the "official" repo, but it still incurs costs in terms of documentation, workflow changes, etc. cheers, --titus -- C. Titus Brown, ctb@msu.edu
On Thu, Jul 1, 2010 at 8:52 AM, anatoly techtonik <techtonik@gmail.com> wrote:
After reading PEP 384 and PEP 385 (finally) I got a strong impression that they are not ready for the change (read below the line for details), because they do not propose any workflow. So, instead of rushing with migration I'd like to propose incremental change rather than revolutionary that will allow people to taste what it like to work with Mercurial and update all relevant papers on the website.
This migration is far from "rushed". Workflow will need to be documented and we need a working hg setup a little while before the official migration. Both of those said, I personally think this has dragged on long enough. jesse
On Thu, Jul 1, 2010 at 07:31, R. David Murray <rdmurray@bitdance.com> wrote:
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik <techtonik@gmail.com> wrote:
Primary concern is that will happen with central Subversion repository. There are a plenty of private tools and automated scripts that were written to work with central Subversion repository, so it is important that central Subversion repository continue to operate and be synchronized.
However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching.
It would certainly be possible to have snapshots of the hg repo be committed into SVN, but I think people will actually notice sooner that it's dead if we don't update it at all anymore.
I remember the decision as being that SVN would be read-only after the switch. Which will cause some pain, yes, but probably not as much pain as trying to keep both workflows available would.
The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python.
Mercurial is relatively flexible in that there are lots of ways you can do this, and so I find that, certainly for the local parts of the workflow (e.g. those that don't directly affect the repo that everyone sees), I don't want to mandate a certain workflow. On the other hand,
And this is the reason that Martin says that a *working* (final configuration) repo must be available for some time before the transition takes place, so that we can all experiment and figure out what external workflow is needed, and document what people find to be useful internal workflows.
I think someone needs to say, "OK, what's up is how it is going to be, you've got X weeks to make sure you can work with it and then we cut over" before the balance of the dev community is going to actually try working with it. But one or more volunteers could make the first cut at the workflow docs right now, I would think, and that would be a big help for this process
I know I would have preferred to have such docs before I gave it a try...but I need to be able to talk intelligently about HG at PyOhio, so I need to start learning it this week.
Here is a *really* quick-and-dirty approach for non-committers to create a patch they can submit. This is not extensively tested so some other Hg expert should back me up on this before telling anyone that this is the simplest way. I am also not saying this is how we will want people to contribute in the long run, but this does work and matches how svn does things well enough that people shouldn't get thrown by the details. 1. Contributor clones the repo 2. Contributor makes changes, committing as they go 3. Contributor runs ``hg outgoing --patch --git > patch.diff`` 4. Committer runs ``hg patch --no-commit patch.diff`` 5. Committer does the usual review->commit thing Basically this creates git-style diffs that one can shuttle around. I think you can also use ``patch -p1`` or git-apply to apply the patch generated by Mercurial. The other option is using mq (Mercurial Queues), but I personally have not gotten around to learning how to use them so I can't tell you any details. But if the Hg transition is taking too long for you, mq can be used on top of svn w/o issue: http://mercurial.selenic.com/wiki/WorkingWithSubversion#With_MQ_only . This obviously does not cover how committers should backport. That will very between whether it is within 3.x or 3.x to 2.x (or vice-versa). That will require a bit more thought and discussion. And finally, http://hginit.com/ is one of the best Hg intros I have come across for explaining fundamentals.
The workflow described by Brett looks like a patch-and-email one. It’s used by the Mercurial team itself, and has the advantage of not cluttering the history with lots of changes, since you only apply one patch in the end. However, in the not-so-long run I feel that a simpler and more mercurialic workflow would be a changesets-and-repos one. 1. Contributor clones the repo. 2. Contributor makes changes, committing as needed. 3. Contributor pushes to some public location and asks for pulling. 4. Core dev reviews and pulls from that repo into the official one. (optional step) Core dev may make additional edits (e.g. to NEWS and ACKS) in another changeset. One advantage of DVCS is that it separates the step of getting ideas from brain to code (commit) from the step of approving code and putting it into the official repo (pull). Having both the contributor and the core dev doing commits seems counter-natural to me. Advanced users may use MQ or pbranches or bookmarks to refine patches, but basic usage (commit and pull) still seems worthwhile to me.
And finally, http://hginit.com/ is one of the best Hg intros I have come across for explaining fundamentals. Agreed, although I’m not sure whether I’d call it a long introduction or a short tuto :) The “reeducation for Subversion users” page is helpful. hgtip.com has bite-sized tips for daily use, and http://hgbook.red-bean.com/ is an excellent read.
Regards
On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik <techtonik@gmail.com> wrote: 4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python- dev archives but was unable to find much.
I just set up a PSF account on BitBucket for hosting the Pulse newsletter repository. I can assist with setting up a public repository for the source under that account, too. Doug
On 1 July 2010 20:58, Brett Cannon <brett@python.org> wrote:
Here is a *really* quick-and-dirty approach for non-committers to create a patch they can submit. This is not extensively tested so some other Hg expert should back me up on this before telling anyone that this is the simplest way. I am also not saying this is how we will want people to contribute in the long run, but this does work and matches how svn does things well enough that people shouldn't get thrown by the details.
1. Contributor clones the repo 2. Contributor makes changes, committing as they go 3. Contributor runs ``hg outgoing --patch --git > patch.diff`` 4. Committer runs ``hg patch --no-commit patch.diff`` 5. Committer does the usual review->commit thing
Basically this creates git-style diffs that one can shuttle around. I think you can also use ``patch -p1`` or git-apply to apply the patch generated by Mercurial.
I'd suggest the patchbomb extension (distributed with Mercurial) hg email --outgoing --to dest@somewhere sends a series of patches to the given email address. This is what the Mercurial developers use (with the to address being the mercurial-dev list). Or maybe better, hg email --outgoing --bundle which sends a binary bundle of all outgoing changesets. You can use --to to send the email to something like roundup (will Roundup extract an attachment from an email and add it to the issue as a file? That would be particularly neat...) Paul.
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon <brett@python.org> wrote:
Here is a *really* quick-and-dirty approach for non-committers to create a patch they can submit. This is not extensively tested so some other Hg expert should back me up on this before telling anyone that this is the simplest way. I am also not saying this is how we will want people to contribute in the long run, but this does work and matches how svn does things well enough that people shouldn't get thrown by the details.
1. Contributor clones the repo 2. Contributor makes changes, committing as they go 3. Contributor runs ``hg outgoing --patch --git > patch.diff`` 4. Committer runs ``hg patch --no-commit patch.diff`` 5. Committer does the usual review->commit thing
Basically this creates git-style diffs that one can shuttle around. I think you can also use ``patch -p1`` or git-apply to apply the patch generated by Mercurial.
I'd suggest the patchbomb extension (distributed with Mercurial)
hg email --outgoing --to dest@somewhere sends a series of patches to the given email address. This is what the Mercurial developers use (with the to address being the mercurial-dev list). Or maybe better, hg email --outgoing --bundle which sends a binary bundle of all outgoing changesets. You can use --to to send the email to something like roundup (will Roundup extract an attachment from an email and add it to the issue as a file? That would be particularly neat...)
Wouldn't it be cool if we could hook this up to Rietveld? Other than that, while I sometimes review patches in email, I do not think patches in a tracker are the best way to manage these. A dvcs's biggest strength is in branches, so we should use those as much as possible. -Barry
Am 01.07.2010 23:57, schrieb Paul Moore:
will Roundup extract an attachment from an email and add it to the issue as a file? That would be particularly neat...
It actually does. Feel free to try it out on the life system (i.e. not worrying about bogus issues - we have several test issues alread). Regards, Martin
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw <barry@python.org> wrote:
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon <brett@python.org> wrote:
Here is a *really* quick-and-dirty approach for non-committers to create a patch they can submit. This is not extensively tested so some other Hg expert should back me up on this before telling anyone that this is the simplest way. I am also not saying this is how we will want people to contribute in the long run, but this does work and matches how svn does things well enough that people shouldn't get thrown by the details.
1. Contributor clones the repo 2. Contributor makes changes, committing as they go 3. Contributor runs ``hg outgoing --patch --git > patch.diff`` 4. Committer runs ``hg patch --no-commit patch.diff`` 5. Committer does the usual review->commit thing
Basically this creates git-style diffs that one can shuttle around. I think you can also use ``patch -p1`` or git-apply to apply the patch generated by Mercurial.
I'd suggest the patchbomb extension (distributed with Mercurial)
hg email --outgoing --to dest@somewhere sends a series of patches to the given email address. This is what the Mercurial developers use (with the to address being the mercurial-dev list). Or maybe better, hg email --outgoing --bundle which sends a binary bundle of all outgoing changesets. You can use --to to send the email to something like roundup (will Roundup extract an attachment from an email and add it to the issue as a file? That would be particularly neat...)
Wouldn't it be cool if we could hook this up to Rietveld?
Don't see why not; it already has Hg support, IIRC.
Other than that, while I sometimes review patches in email, I do not think patches in a tracker are the best way to manage these. A dvcs's biggest strength is in branches, so we should use those as much as possible.
As I said, quick-and-dirty. It will take discussion to decide what we want to ask non-committers to do, weighing cost of complexity of the approach for people new to DVCS in general and Hg in particular, resource access such as a publicly accessible place to push repos, what data format we prefer, etc. I just wanted to give David something to go to PyOhio with that I know will be simple to explain and will always work.
On Thu, 1 Jul 2010 15:26:12 -0700 Brett Cannon <brett@python.org> wrote:
As I said, quick-and-dirty. It will take discussion to decide what we want to ask non-committers to do,
I don't think we have to ask them to do anything special, as long as they can submit their contributions under the form of a patch. Whether they use named branches, separate clones, mercurial queues, the pbranch extension, or even the basic hg-as-an-svn-synonym workflow you suggested should be none of our business, IMO. A DVCS allows non-committers to manage (augment, fix, synchronize) their patches more easily until they get committed. I don't think it will change the committers' work a lot, though. I don't know how Mercurial could make the task of committing an outsider's patch significantly simpler. Regards Antoine.
On 2 July 2010 08:07, Barry Warsaw <barry@python.org> wrote:
Other than that, while I sometimes review patches in email, I do not think patches in a tracker are the best way to manage these. A dvcs's biggest strength is in branches, so we should use those as much as possible.
I changed my team over from ClearCase to Mercurial in the last 3 months (just before we were made redundant ... :) Obviously our usage was coloured by our previous use of ClearCase, but the workflow I found that worked best was along the lines of the following. 1. Central server for the team, with a repository for each version (e.g. 2.6, 2.7, 3.2) where the default branch is the "trunk". Later versions get cloned from a previous version at a particular tag, and merges between versions are always forwards (if there's a need to merge backwards, we cherry-pick the change by doing an hg export of the appropriate versions). 2. Developer made at least one clone of the appropriate repo, but could have as many as they liked. Generally would have one local repo for production work, and others for prototyping, exploratory work, etc - stuff that you may not want in the central repo. 3. Each change is developed in its own named branch, named for the task number. Local commits are performed as often as possible - no requirement that any particular commit was compilable so long as it was on the task's named branch. 4. Changesets are pushed to the central repository (requires forcing, as Hg doesn't like you pushing new named branches). The named branch should be compilable, pass unit tests, etc at this point. Generally preferred not to edit the history or anything, but if there was something egregious 5. Other developers pulled from the central repository and reviewed (integration with ReviewBoard or Reitveld was planned, but ran out of time). This often led to a pair programming session on the reviewers machine where comments were addressed directly. 6. Named branch was closed and merged to the main/trunk branch (in our case, default). In our case this was usually done by the author - for Python this would be done by a committer. 7. Merged default branch was pushed to the central repo, which triggered a continuous build. This approach is quite contrary to that favoured by the Mercurial developers, but we found it had the following advantages: a. Central team repo made backup and continuous build simple. b. Named branches for tasks made the whole "what do I do with these unfinished changes?" question moot - you commit them to your named branch. c. Switching between tasks is incredibly simple - you already have your workspace set up (e.g. Eclipse) and just update to the appropriate named branch. No need to set up multiple workspaces. d. Similarly, switching to someone else's named branch is just as easy (for review, pair programming, etc). e. Named branches make it very obvious what needs to be merged for any particular task. f. Easier to follow in the log/graphical log as everything was "tagged" with what task it was against. The only issue was that if a branch was abandoned, it would show up in "hg branches" unless it was closed - but closing wasn't a problem since you can always reopen if necessary. Tim Delaney
On 2 July 2010 08:07, Barry Warsaw <barry@python.org> wrote:
Other than that, while I sometimes review patches in email, I do not think patches in a tracker are the best way to manage these. A dvcs's biggest strength is in branches, so we should use those as much as possible.
7. Merged default branch was pushed to the central repo, which triggered a continuous build.
Clarification here - I mean that a committer would merge it to default,
On 2 July 2010 09:08, Tim Delaney <timothy.c.delaney@gmail.com> wrote: then pull it into the main python repo - there would be one that anyone could push changes to, and those named branches would then be cherry-picked to be merged and pulled into the main repo by committers. Or something along those lines. Tim Delaney
On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote:
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw <barry@python.org> wrote:
Other than that, while I sometimes review patches in email, I do not think patches in a tracker are the best way to manage these. A dvcs's biggest strength is in branches, so we should use those as much as possible.
As I said, quick-and-dirty. It will take discussion to decide what we want to ask non-committers to do, weighing cost of complexity of the approach for people new to DVCS in general and Hg in particular, resource access such as a publicly accessible place to push repos, what data format we prefer, etc. I just wanted to give David something to go to PyOhio with that I know will be simple to explain and will always work.
That's cool. I've had pretty good luck asking contributors on other project to create branches and merge proposals (a Launchpad feature that triggers code reviews), even when they first posted patches to a tracker or mailing list. I'm confident most of our non-committers will find it pretty easy, especially if we can provide a guide for the basics. -Barry
anatoly techtonik writes:
After reading PEP 384 and PEP 385 (finally) I got a strong impression that they are not ready for the change (read below the line for details), because they do not propose any workflow.
This was deliberate. There are a lot of different workflows, and we are not in a position to tell people to change them.
So, instead of rushing with migration
We are hardly rushing. You're just late to the party. Catch your breathe, get a beer, have a good time. No?
I'd like to propose incremental change rather than revolutionary that will allow people to taste what it like to work with Mercurial and update all relevant papers on the website.
Been there, done that, if that's the way it's gonna be, I won't touch it. It's much too painful for those who are doing the work, compared to the small benefits received by the community as a whole.
I am willing to collaborate for getting this system in place before EuroPython even if I won't find a chance to get there.
Are you also willing to maintain the system indefinitely? I haven't yet seen such a system that really works without regular attention from a human.
However, PEP 385 "The Future of Subversion" [1] does not propose any way to keep Subversion repository in sync. "it will probably live on for a bit" phrase looks like Subversion will be immediately dead after switching.
Yes, that is the intent. For old versions, the Subversion repo will be available read-only. For casual contributors, there's a one-time set up cost of pulling a local mirror from the public repository. For those familiar with Mercurial, there is nothing but joy to be found in the transition. For folks like you, heavily invested in Subversion-based private automation, yes, there will be some pain.
The second concern is workflow. Even after getting my hands dirty I still can't find the best solution for working with Mercurial copy of Python. In Subversion I do shallow checkouts of interesting features when I run into one bug or another. Not all patches are ready, so they stay in those checkouts as uncommitted diffs.
For this kind of workflow, Mercurial queues (mq) is probably the best solution. Unfortunately, it will require you to write some additional scripts to get the same level of convenience you have now.
To be prepared for conflicts I review code with `svn log -vr base:head` before updating. But with Mercurial I see two major problems with my workflow (which I am unlikely to change for the next few weeks due to heavy automation): 1. No shallow checkouts - that means that I have to copy 200Mb+ for every patch I have
No, you don't. You make links to 200MB+ (unless you're on Windows, where I don't know how this works). This is much cheaper than copying, though not as cheap as in git. I don't hesitate to make branches in Mercurial. Alternatively, for localized bugfixes, doc typos, and the like, one "little-fixes" branch with an mq patch or two for each is a reasonable way to work.
2. No `hg log` command to see changes in my branch from remote repository before fetching them (I used to invoke `hg incoming`, but ended up with fetching everything with `hg pull` and then using `hg log -vr .:tip`, because `hg inc` didn't show changes that were already pulled, but not updated in wc, and `hg log` could not show incoming)
3. There is no clear branch separation in my working copy. I don't know how to diff files in different branches without copying 200Mb+ clone. I don't know how to diff my files with remote repository without pulling it.
If you're at all serious about working with Mercurial, you don't do any operations except pull (and push, if you're a committer) against the remote. You keep a local pristine mirror of the remote repository, which you update frequently, and all of your work revolves around that rather than around contact with upstream. This does mean that when upstream uses a repo-per-branch model you have to keep multiple mirrors. On the other hand, you can work directly in branches that you work on only infrequently, and also use Mercurial queues to avoid making branches if you don't want to.
4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain.
No loss, either, since that's the current workflow, and maintaining as much of the current workflow (possibly with "new spellings" of the commands implementing it) was an explicit goal for PEP 374. I assume that carries over to PEP 385. If you and some others working on a common project want to work with branches rather than patches (email or tracker), then if there's a committer in the group, you can set up a branch on code.python.org. If not, you can use bitbucket or something. Yes, it's a bit of extra effort for you.
So from these PEPs I can't really see how Mercurial solves problems with development. I can feel that it doesn't solve my problems, but I see no way where I can submit my user story.
It doesn't solve problems with development, and that is not the intent of the PEPs AIUI. IMO, the theme of these PEPs is to maintain current practices and gives a platform for improved practices in the future.
I would put accent on keeping mirror of Subversion as easy way to contribute for those who are not yet ready for DVCS.
"Accent" won't cut it. Effort is needed. That effort won't be mine, I don't know how anybody else likely to be involved feels about it. And in fact, Mercurial makes it quite a bit *easier* for *casual* contributors to work on the code base. *All* of my work based on projects using Subversion (or CVS) is done from colocated DVCS branches. The only difference from my basic DVCS workflow is (1) the synch to upstream command is "svn up" rather than "hg pull -u", and (2) those changes must be committed to the DVCS (automated by script). It also is clearly going to make more effective workflows for many of the core developers. AFAIK, assuming the issues that have been raised in PEP 385 and the tracker are resolved, other core developers agree that the transition will have an acceptably low impact on them. Admittedly, it seems this transition is going to affect you adversely. That's unfortunate, but AFAIK you are in a small minority. Note that this is my current understanding of the situation. As the transition proceeds (and we are still very much in a planning phase, where anything could be changed), it may become clear that active developers in your situation are more numerous than I (we?) think. Also, any suggestions you make, including maintaining the Svn repository, will be taken seriously ... but many of them, specifically the decision to freeze the Svn repo once we cut over, have already been thought through carefully. Doesn't mean that they can't be changed, but you do have to accept that you're going to need to provide evidence that changing the decisions will benefit the community as a whole.
Wouldn't it be cool if we could hook this up to Rietveld?
I can also highly recommend ReviewBoard_ since it already speaks Mercurial. My company has been using it since Dec. 2009 as an invaluable addition to in-person code reviews for both Subversion and Mercurial repos. FWIW, I've got an instance at this address for anybody who wants to try it out: http://reviews.meatballhat.com Cheers, -- ~ Dan .. _ReviewBoard: http://www.reviewboard.org/
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull <stephen@xemacs.org> wrote:
No, you don't. You make links to 200MB+ (unless you're on Windows, where I don't know how this works). This is much cheaper than copying, though not as cheap as in git. I don't hesitate to make branches in Mercurial.
It can still do hardlinks on Windows, provided the repo is on NTFS (and I think NTFS supports only hardlinks within the same partition). Cheers, Dirkjan
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller <jnoller@gmail.com> wrote:
This migration is far from "rushed". Workflow will need to be documented and we need a working hg setup a little while before the official migration. Both of those said, I personally think this has dragged on long enough.
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment, so the current step is to create these mirrors to try releasing 3.2 from them. Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right? -- anatoly t.
On 02/07/2010 08:25, Dirkjan Ochtman wrote:
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull<stephen@xemacs.org> wrote:
No, you don't. You make links to 200MB+ (unless you're on Windows, where I don't know how this works). This is much cheaper than copying, though not as cheap as in git. I don't hesitate to make branches in Mercurial.
It can still do hardlinks on Windows, provided the repo is on NTFS (and I think NTFS supports only hardlinks within the same partition).
Strictly: on the same volume. (Which will generally but not always amount to: under the same drive letter) TJG
Am 01.07.2010 23:25, schrieb Doug Hellmann:
On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik <techtonik@gmail.com <mailto:techtonik@gmail.com>> wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting the central repository on a site such as bitbucket or github? I tried searching the python-dev archives but was unable to find much.
I just set up a PSF account on BitBucket for hosting the Pulse newsletter repository. I can assist with setting up a public repository for the source under that account, too.
Bitbucket usually uses the "mirror" account for pure mirror repos; but we can probably use our own as well :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Am 02.07.2010 09:27, schrieb anatoly techtonik:
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller <jnoller@gmail.com> wrote:
This migration is far from "rushed". Workflow will need to be documented and we need a working hg setup a little while before the official migration. Both of those said, I personally think this has dragged on long enough.
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment,
There are repositories at http://hg.python.org/; the "cpython" one represents the result of conversion at some point in time.
so the current step is to create these mirrors to try releasing 3.2 from them.
I don't know about "try" -- personally I don't see a difference for the release procedure, no matter where the source comes from. I also have no problems releasing a first alpha from SVN, and the following from Hg.
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Am 02.07.2010 01:05, schrieb Antoine Pitrou:
On Thu, 1 Jul 2010 15:26:12 -0700 Brett Cannon <brett@python.org> wrote:
As I said, quick-and-dirty. It will take discussion to decide what we want to ask non-committers to do,
I don't think we have to ask them to do anything special, as long as they can submit their contributions under the form of a patch. Whether they use named branches, separate clones, mercurial queues, the pbranch extension, or even the basic hg-as-an-svn-synonym workflow you suggested should be none of our business, IMO.
A DVCS allows non-committers to manage (augment, fix, synchronize) their patches more easily until they get committed. I don't think it will change the committers' work a lot, though. I don't know how Mercurial could make the task of committing an outsider's patch significantly simpler.
I do: if the outsider creates a patch in a personal branch, he is more likely to merge with the trunk every now and then as if he creates a patch once and then puts it on the tracker. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On 07/02/2010 10:33 AM, Georg Brandl wrote:
Am 02.07.2010 09:27, schrieb anatoly techtonik:
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller <jnoller@gmail.com> wrote:
This migration is far from "rushed". Workflow will need to be documented and we need a working hg setup a little while before the official migration. Both of those said, I personally think this has dragged on long enough.
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment,
There are repositories at http://hg.python.org/; the "cpython" one represents the result of conversion at some point in time.
http://code.python.org/hg/ looks like a working mercurial mirror of current CPython svn. It's probably nothing you'd like to switch to as such since it doesn't replace svn usernames with names/e-mail addressed (as I gather was planned), but it does get updated. As one of those potential contributors that are new to the game and actually know and love Mercurial, I've never actually checked out a Python subversion branch, and have based the few patches I have written on http://code.python.org/hg/branches/py3k/ Thomas
hg.python.org/cpython is a test setup for people working on the transition. It is not guaranteed to be usable, it usually lags, and it will be rewritten before the real switch IIRC. code.python.org/hg is a mirror kept in sync for use by contributors who don’t want to use Subversion now. After the switch, hg.python.org/cpython will be the official repo, and code.python.org/hg will probably be closed. HTH Regards
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo <merwok@netwok.org> wrote:
hg.python.org/cpython is a test setup for people working on the transition. It is not guaranteed to be usable, it usually lags, and it will be rewritten before the real switch IIRC.
code.python.org/hg is a mirror kept in sync for use by contributors who don’t want to use Subversion now.
After the switch, hg.python.org/cpython will be the official repo, and code.python.org/hg will probably be closed.
Why this transition is not described in PEP? How code.python.org/hg is synchronized with Subversion? Why it is not possible to leave code.python.org/hg as is in slave mode and then realtime replication is ready just switch master/slave over? -- anatoly t.
On Fri, 2 Jul 2010 15:22:44 +0300 anatoly techtonik <techtonik@gmail.com> wrote:
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo <merwok@netwok.org> wrote:
hg.python.org/cpython is a test setup for people working on the transition. It is not guaranteed to be usable, it usually lags, and it will be rewritten before the real switch IIRC.
code.python.org/hg is a mirror kept in sync for use by contributors who don’t want to use Subversion now.
After the switch, hg.python.org/cpython will be the official repo, and code.python.org/hg will probably be closed.
Why this transition is not described in PEP?
Because it's not a transition. It's a mirror. It was put in place before the hg migration plan was accepted, IIRC.
How code.python.org/hg is synchronized with Subversion?
What does your question mean exactly? It's a mirror (well, a set of mirrors) and is synchronized roughly every 5 minutes.
Why it is not possible to leave code.python.org/hg as is in slave mode and then realtime replication is ready just switch master/slave over?
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). Regards Antoine.
anatoly techtonik writes:
Why this transition is not described in PEP?
Please reread the whole thread, and the PEP. PEP 385 is *incomplete* (see the red Warning at the top), and the original proponent *is not going to have enough time to complete it soon*. That being the case, Martin suggested that either we find a new proponent or postpone the transition to next year. We're currently in the process of finding a new proponent and supporting cast, and determining what, if anything, we're going to do about the transition over the next few months. There is no reason at this point to suppose the transition can't be complete by the end of summer. However, as always, the devil is in the details, and one of them may be a showstopper. We'll just have to see about that.
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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. This information really belongs in www.python.org/dev/ rather than only in the mailing list. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
On Fri, 2 Jul 2010 09:09:48 -0400 Fred Drake <fdrake@acm.org> wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
I'm not sure. Contributors don't really have to know about the specifics of the temporary repositories used for conversion tests. www.python.org/dev/ already points to the stable, up-to-date mirrors; I don't think it's worth complicating that page. Regards Antoine.
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl <g.brandl@gmx.net> wrote:
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment,
There are repositories at http://hg.python.org/; the "cpython" one represents the result of conversion at some point in time.
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only.
Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow? -- anatoly t.
Am 02.07.2010 15:48, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl <g.brandl@gmx.net> wrote:
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment,
There are repositories at http://hg.python.org/; the "cpython" one represents the result of conversion at some point in time.
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example.
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only.
Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou <solipsis@pitrou.net> wrote:
I'd love to see a more detailed description of this, including why someone new to Mercurial would choose one over the other.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
I'm not sure. Contributors don't really have to know about the specifics of the temporary repositories used for conversion tests.
Very much agreed. Cheers, Dirkjan
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl <g.brandl@gmx.net> wrote:
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example.
Does anybody here know how Mercurial calculates the IDs? From that I remember it is author + message + diff content. What can change there?
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only.
Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely.
It doesn't require manpower. It requires automation. Considering that the biggest problem now is to get sane lossless conversion, we should elaborate on getting this in place. After that I would still follow the path of setting realtime mirror for X weeks that could be replicated by bitbucket, launchpad and other services to see how people pickup the changes. As PEP 384 says - the transition is mostly to make lives of outside contributors easier. Core developers can wait for a while. -- anatoly t.
On Fri, Jul 2, 2010 at 16:17, anatoly techtonik <techtonik@gmail.com> wrote:
As PEP 384 says - the transition is mostly to make lives of outside contributors easier. Core developers can wait for a while.
I think a lot of the core developers also want this because it makes their lives better. Also, several people so far have stated that they wouldn't be interested in a SVN bridge -- AFAICT you are the only one. If you really want this, maybe you can set it up and maintain it yourself? Everything about the repo is freely available, so you can just get it going. Cheers, Dirkjan
On Fri, Jul 2, 2010 at 10:17 AM, anatoly techtonik <techtonik@gmail.com> wrote:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl <g.brandl@gmx.net> wrote:
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example.
Does anybody here know how Mercurial calculates the IDs? From that I remember it is author + message + diff content. What can change there?
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only.
Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely.
It doesn't require manpower. It requires automation. Considering that the biggest problem now is to get sane lossless conversion, we should elaborate on getting this in place. After that I would still follow the path of setting realtime mirror for X weeks that could be replicated by bitbucket, launchpad and other services to see how people pickup the changes.
As PEP 384 says - the transition is mostly to make lives of outside contributors easier. Core developers can wait for a while.
No, we can't. We *have* been waiting.
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl <g.brandl@gmx.net> wrote:
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example.
Does anybody here know how Mercurial calculates the IDs? From that I remember it is author + message + diff content. What can change there?
The parents IDs also are part of that hash. Apart from that, author and message can change as well, since SVN/CVS-style committer names will be mapped to Mercurial-style name + email, and the message can have "[rev ...]" appended or prepended or not.
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right?
No; as soon as we switch, SVN will be read-only.
Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely.
It doesn't require manpower. It requires automation.
And who, do you think, is going to implement that automation?
Considering that the biggest problem now is to get sane lossless conversion, we should elaborate on getting this in place.
Ah, the mysterious "we".
After that I would still follow the path of setting realtime mirror for X weeks that could be replicated by bitbucket, launchpad and other services to see how people pickup the changes.
As PEP 384 says - the transition is mostly to make lives of outside contributors easier. Core developers can wait for a while.
Anatoly, I don't know what you are trying to achieve here. The decision to switch to Mercurial as soon as possible given our manpower restriction has been made at PyCon 2009. Since then, there has been progress, albeit slow, towards that switch, and now that has come into reach, you start questioning anything and everything. This is neither productive, nor have you shown any willingness to actually *do* something to help. You claim you do not have enough time for that; looking at the multitude of topics you're trying to force a discussion about, I wonder if you couldn't write one decent patch instead of ten complaining mails, and make both you and us happier in the process. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Georg Brandl wrote:
Am 02.07.2010 15:48, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl <g.brandl@gmx.net> wrote:
So, if I understand correctly - there are no Mercurial mirrors for testing at the moment, There are repositories at http://hg.python.org/; the "cpython" one represents the result of conversion at some point in time. What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository?
The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example.
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right? No; as soon as we switch, SVN will be read-only. Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely.
The code.python.org/hg mirror has been running for many months now: As a non-committer, I have been able to use its 2.6 branch and the trunk with hg to test / develop / submit patches. Can somebody comment on how much ongoing effort is required to keep that mirror running? I know that the hg / git / bzr mirrors I set up for the repoze SVN repository haven't require any ongoing effort, after the initial day or two of setup effort. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkwuARwACgkQ+gerLs4ltQ6rUgCfU2NSdjz+pIY1I95OnpRMU5Fx 22gAn1Zu+KGOaNgYJYJ7c9NKzr3ICxS+ =wIB0 -----END PGP SIGNATURE-----
On Jul 02, 2010, at 11:09 AM, Tres Seaver wrote:
Can somebody comment on how much ongoing effort is required to keep that mirror running?
I'm guess "zero". Other than uploading new ssh keys, I think our svn master has been humming along pretty well without intervention. I know that the bzr mirrors on Launchpad have been zero effort as well. -Barry
Am 02.07.2010 17:09, schrieb Tres Seaver:
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right? No; as soon as we switch, SVN will be read-only. Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow?
I don't think that we have enough manpower to maintain such a bridge indefinitely.
The code.python.org/hg mirror has been running for many months now: As a non-committer, I have been able to use its 2.6 branch and the trunk with hg to test / develop / submit patches.
Can somebody comment on how much ongoing effort is required to keep that mirror running? I know that the hg / git / bzr mirrors I set up for the repoze SVN repository haven't require any ongoing effort, after the initial day or two of setup effort.
As Barry says, that's not a problem. What's problematic is the continued use of the current Subversion setup as a read-write bridge to the Mercurial repo, once the switch to Mercurial as the main platform has happened. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
+1 As does a recent essay by Eli Bendersky, IMO. I believe it could lower the barriers for entry into the "non-committer" class of developer. This should make it easier for people to adapt Python to their own purposes whether or not they want to contribute to the open source code base, but also encourage people to investigate the compiler's innards. http://eli.thegreenplace.net/2010/06/30/python-internals-adding-a-new-statem... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
Stephen J. Turnbull wrote:
anatoly techtonik writes:
Why this transition is not described in PEP?
Please reread the whole thread, and the PEP.
PEP 385 is *incomplete* (see the red Warning at the top), and the original proponent *is not going to have enough time to complete it soon*. That being the case, Martin suggested that either we find a new proponent or postpone the transition to next year. We're currently in the process of finding a new proponent and supporting cast, and determining what, if anything, we're going to do about the transition over the next few months.
There is no reason at this point to suppose the transition can't be complete by the end of summer. However, as always, the devil is in the details, and one of them may be a showstopper. We'll just have to see about that.
And, as always, a way to get better insight and help speed the process along is to join the cast ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
Georg Brandl wrote:
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl <g.brandl@gmx.net> wrote:
What is the problem with realtime synchronization and working with already up to date Mercurial mirror of central SVN repository? The specifics of the conversion process are not nailed down yet. Therefore, the exact translation of SVN to Hg commits will change, and with it the Mercurial revision IDs, for example. Does anybody here know how Mercurial calculates the IDs? From that I remember it is author + message + diff content. What can change there?
The parents IDs also are part of that hash. Apart from that, author and message can change as well, since SVN/CVS-style committer names will be mapped to Mercurial-style name + email, and the message can have "[rev ...]" appended or prepended or not.
Development will continue in SVN repository until everybody is ready for final migration in X weeks later. Is that right? No; as soon as we switch, SVN will be read-only. Why don't allow people who already know Mercurial use Mercurial and those who prefer Subversion use that. If Mercurial allows to submit to Subversion - why people can't use that while we writing tutorials and answering question about workflow? I don't think that we have enough manpower to maintain such a bridge indefinitely. It doesn't require manpower. It requires automation.
And who, do you think, is going to implement that automation?
Considering that the biggest problem now is to get sane lossless conversion, we should elaborate on getting this in place.
Ah, the mysterious "we".
After that I would still follow the path of setting realtime mirror for X weeks that could be replicated by bitbucket, launchpad and other services to see how people pickup the changes.
As PEP 384 says - the transition is mostly to make lives of outside contributors easier. Core developers can wait for a while.
Anatoly, I don't know what you are trying to achieve here. The decision to switch to Mercurial as soon as possible given our manpower restriction has been made at PyCon 2009. Since then, there has been progress, albeit slow, towards that switch, and now that has come into reach, you start questioning anything and everything. This is neither productive, nor have you shown any willingness to actually *do* something to help. You claim you do not have enough time for that; looking at the multitude of topics you're trying to force a discussion about, I wonder if you couldn't write one decent patch instead of ten complaining mails, and make both you and us happier in the process.
+1 That's the spirit, Georg. Anatoly, I had an email along these lines saved pending transmission, but I have deleted it now. Let's make things better rather than dwell on how rotten everything is and how it could be /so/ much better if "we" would get off our butts and do {stuff}. ;-) The more {stuff} done I can point to as PSF chairman the easier it will be to justify raising funds to help make things better still. I'd rather see devs developing than administering systems. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Fri, 02 Jul 2010 12:55:56 -0400 Steve Holden <steve@holdenweb.com> wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
+1
As does a recent essay by Eli Bendersky, IMO. I believe it could lower the barriers for entry into the "non-committer" class of developer. This should make it easier for people to adapt Python to their own purposes whether or not they want to contribute to the open source code base, but also encourage people to investigate the compiler's innards.
With the moratorium on language constructs and builtins (not only in letter until 3.3, but more generally in spirit), I don't think we should encourage it at all, for such contributions would surely be rejected. Rather than fancy syntax propositions or wild semantic changes/enhancements (such as have often been proposed on python-ideas), what we need is humbler but more useful work on stdlib bugs and improvements, as well as documentation and tutorials. (what's more, those two kinds of contributions are likely to attract two different kinds of people, which means that people whose syntax patches get refused won't necessarily start contributing stdlib or documentation patches...) Regards Antoine.
On Fri, Jul 2, 2010 at 1:12 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 02 Jul 2010 12:55:56 -0400 Steve Holden <steve@holdenweb.com> wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
+1
As does a recent essay by Eli Bendersky, IMO. I believe it could lower the barriers for entry into the "non-committer" class of developer. This should make it easier for people to adapt Python to their own purposes whether or not they want to contribute to the open source code base, but also encourage people to investigate the compiler's innards.
With the moratorium on language constructs and builtins (not only in letter until 3.3, but more generally in spirit), I don't think we should encourage it at all, for such contributions would surely be rejected.
Rather than fancy syntax propositions or wild semantic changes/enhancements (such as have often been proposed on python-ideas), what we need is humbler but more useful work on stdlib bugs and improvements, as well as documentation and tutorials.
(what's more, those two kinds of contributions are likely to attract two different kinds of people, which means that people whose syntax patches get refused won't necessarily start contributing stdlib or documentation patches...)
Regards
Antoine.
I completely and wholeheartedly agree with Antoine. I'm hoping the sprints thing will help with this - the stuff outside of the "deep core" needs a lot more help and TLC. jesse
Antoine Pitrou wrote:
On Fri, 02 Jul 2010 12:55:56 -0400 Steve Holden <steve@holdenweb.com> wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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.
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
+1
As does a recent essay by Eli Bendersky, IMO. I believe it could lower the barriers for entry into the "non-committer" class of developer. This should make it easier for people to adapt Python to their own purposes whether or not they want to contribute to the open source code base, but also encourage people to investigate the compiler's innards.
With the moratorium on language constructs and builtins (not only in letter until 3.3, but more generally in spirit), I don't think we should encourage it at all, for such contributions would surely be rejected.
Rather than fancy syntax propositions or wild semantic changes/enhancements (such as have often been proposed on python-ideas), what we need is humbler but more useful work on stdlib bugs and improvements, as well as documentation and tutorials.
(what's more, those two kinds of contributions are likely to attract two different kinds of people, which means that people whose syntax patches get refused won't necessarily start contributing stdlib or documentation patches...)
The point was not to encourage experimentation with wild syntax variants (and Bendersky underlines that he knows perfectly well that Python does not need an "until" statement. THe point is to encourage more people to understand that what goes on under the hood is comprehensible. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
anatoly techtonik writes:
To be prepared for conflicts I review code with `svn log -vr base:head` before updating. But with Mercurial I see two major problems with my workflow (which I am unlikely to change for the next few weeks due to heavy automation): 1. No shallow checkouts - that means that I have to copy 200Mb+ for every patch I have
No, you don't. You make links to 200MB+ (unless you're on Windows, where I don't know how this works).
Surprisingly, it works there too due to NTFS hardlinks :-)
This is much cheaper than copying, though not as cheap as in git. I don't hesitate to make branches in Mercurial.
You can have branches inside your repository with Mercurial too, just like in Git. The bookmarks extension is for that. With Mercurial 1.6, you can push and pull bookmarks -- they are no longer local-only. I may work more sequentially than most, but I do all my work on Mercurial using a single clone.
3. There is no clear branch separation in my working copy. I don't know how to diff files in different branches without copying 200Mb+ clone. I don't know how to diff my files with remote repository without pulling it.
If you're at all serious about working with Mercurial, you don't do any operations except pull (and push, if you're a committer) against the remote. You keep a local pristine mirror of the remote repository, which you update frequently, and all of your work revolves around that rather than around contact with upstream.
This does mean that when upstream uses a repo-per-branch model you have to keep multiple mirrors. On the other hand, you can work directly in branches that you work on only infrequently, and also use Mercurial queues to avoid making branches if you don't want to.
That is one option and I think "The Definitive Guide" advocates it. However, you are free to mix the upstream clones into a single clone if you want (with 'hg pull' from different upstream repositories), or you can keep them separate. If the upstream uses a single repository with multiple named brancehs, then you can still maintain separate clones locally, say one per named branch (with 'hg clone http://...#branch' style clones). There is really no contraints on how you can setup your local repositories. -- Martin Geisler Mercurial links: http://mercurial.ch/
I don't know about "try" -- personally I don't see a difference for the release procedure, no matter where the source comes from.
I guess you haven't done a release yet, then :-) Assuming you are going to use https://svn.python.org/projects/sandbox/trunk/release/release.py then you'll have to port that to Mercurial, first. Or, you write your own release tool, as any serious release manager did so far :-) As for the Windows build, I don't know how to do "externals", yet. In particular, I don't think it is a good idea to have all externals in a single Mercurial clone: due to versioning, we have multiple copies of them, which will take quite some space. As a minor problem: I currently have a batch file head.bat, which updates sysmodule.c after a switch to expand HeadURL correctly. Not sure whether this will be needed on Mercurial, or whether the build identification patch is able to learn about tags in the first place. Finally, I wonder how the documentation build process will continue to integrate subversion. I guess you just need to have an svn binary around when building the documentation. Regards, Martin
Am 02.07.2010 15:09, schrieb Fred Drake:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou <solipsis@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. Regards, Martin
Can somebody comment on how much ongoing effort is required to keep that mirror running?
As everybody else indicated: none (I believe). FWIW, the bzr mirror wasn't that self-maintaining: the process started to consume too much memory and got killed; the cron jobs broke, and so on, so we finally switched it of (in favor of the Launchpad mirror that also existed). Regards, Martin
This information really belongs in www.python.org/dev/ rather than only in the mailing list.
+1
As does a recent essay by Eli Bendersky, IMO. I believe it could lower the barriers for entry into the "non-committer" class of developer. This should make it easier for people to adapt Python to their own purposes whether or not they want to contribute to the open source code base, but also encourage people to investigate the compiler's innards.
With the moratorium on language constructs and builtins (not only in letter until 3.3, but more generally in spirit), I don't think we should encourage it at all, for such contributions would surely be rejected.
Rather than fancy syntax propositions or wild semantic changes/enhancements (such as have often been proposed on python-ideas), what we need is humbler but more useful work on stdlib bugs and improvements, as well as documentation and tutorials.
(what's more, those two kinds of contributions are likely to attract two different kinds of people, which means that people whose syntax patches get refused won't necessarily start contributing stdlib or documentation patches...)
Regards
Antoine.
Antoine, I wrote that article, and I agree with everything you say here. I just don't want my intentions to be understood incorrectly. Many readers stopped reading after the title and jumped to conclusions which simply aren't true (as some of the comments on the blog and Reddit demonstrate). Just a couple of quotes from the article itself to show that breaking the moratorium (with which I wholeheartedly agree) is far from my intentions: ----------------------------- This article is an attempt to better understand how the front-end of Python works. Just reading documentation and source code may be a bit boring, so I’m taking a hands-on approach here: I’m going to add an until statement to Python. [...] This article doesn’t attempt to suggest the addition of an until statement to Python. Although I think such a statement would make some code clearer, and this article displays how easy it is to add, I completely respect Python’s philosophy of minimalism. All I’m trying to do here, really, is gain some insight into the inner workings of Python. ----------------------------- Kind regards, Eli
Am 03.07.2010 01:54, schrieb "Martin v. Löwis":
I don't know about "try" -- personally I don't see a difference for the release procedure, no matter where the source comes from.
I guess you haven't done a release yet, then :-)
That's possible :)
Assuming you are going to use
https://svn.python.org/projects/sandbox/trunk/release/release.py
then you'll have to port that to Mercurial, first.
True, but it doesn't look too hard.
Or, you write your own release tool, as any serious release manager did so far :-)
As for the Windows build, I don't know how to do "externals", yet. In particular, I don't think it is a good idea to have all externals in a single Mercurial clone: due to versioning, we have multiple copies of them, which will take quite some space.
True.
As a minor problem: I currently have a batch file head.bat, which updates sysmodule.c after a switch to expand HeadURL correctly. Not sure whether this will be needed on Mercurial, or whether the build identification patch is able to learn about tags in the first place.
I have no solution to that from the top of my head, but it will be dealt with
Finally, I wonder how the documentation build process will continue to integrate subversion. I guess you just need to have an svn binary around when building the documentation.
Since I'm giving specific versions in the makefiles anyway, the easiest solution would be to put them as tarfiles/zipfiles up for download somewhere on python.org, and have a small script that gets them via urllib. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote:
Can somebody comment on how much ongoing effort is required to keep that mirror running?
As everybody else indicated: none (I believe).
OK, cool. I have certainly had no issues using it when working as a non-committer to verify patches, etc., for bugs.python.org issues.
FWIW, the bzr mirror wasn't that self-maintaining: the process started to consume too much memory and got killed; the cron jobs broke, and so on, so we finally switched it of (in favor of the Launchpad mirror that also existed).
Yup, we saw that to, and have the loggerhead server running under supervisor, with a configuration to restart it it exceeds a given amount of RAM. In our case, the cron jobs to update the mirror were actually more easier to set up for bzr (and more stable) than for hg or git, but the hg server was better behaved (the git web bit runs as CGI, IIRC). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkwvXGAACgkQ+gerLs4ltQ55kwCgmO5Z1coKDcRUs/n/MvLVfW9t ul8AmwfnorXyVznEDNyxIX5f2/zNGurI =TIqB -----END PGP SIGNATURE-----
-----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@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@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-----
On 7/3/2010 12:36 PM, Tres Seaver wrote:
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
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?) -- Terry Jan Reedy
On Sat, 03 Jul 2010 14:16:08 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
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?)
Filling less of your disk, actually, since local clones use hardlinks. Also, pulling less data from the network might be interesting if you have a slow connection, or pull from a very heavy or very active repo (which CPython isn't, though). Regards Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terry Reedy wrote:
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?)
I gain having my local changes be in a "scratchpad" repsitory, which I can discard at will without requiring a re-fetch of the whole repository from the mirror server, which takes a loooong time and (apparently) puts significant load on that server. As Antoine noted, hg shares the disk space via hard links where possible; where not, what's a few hundred megabytes, more or less? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkwvjKoACgkQ+gerLs4ltQ7aUgCdHeUOkSTDQYefjih8WMH+OXkL 3E4AoLjk7mtG3E8ayxK1NDMlbkQweIiY =40ji -----END PGP SIGNATURE-----
On Sat, Jul 3, 2010 at 11:36 AM, Tres Seaver <tseaver@palladion.com> wrote:
- - 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
My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently: This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
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.
I think your description already falls into the "advanced user" category. The new-to-mercurial committer should (IMO) use a "what if it still was svn" workflow, which uses hg pull/up/commit/push. That can only work if pushing really has the desired effect, which isn't the case for any of the installations that we operate. When the test-for-two-weeks installation becomes available, the new-to-hg users will have a chance to learn how to use it without fear of breaking anything. Until then, they should just remain patient. Regards, Martin
On Sun, 04 Jul 2010 00:51:58 +0200 "Martin v. Löwis" <martin@v.loewis.de> wrote:
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.
I think your description already falls into the "advanced user" category. The new-to-mercurial committer should (IMO) use a "what if it still was svn" workflow, which uses hg pull/up/commit/push.
This assumes they are accustomed to SVN. I guess not all people are, although it is certainly a common skill. Regards Antoine.
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
My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently:
This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch?
IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway). I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required? Regards, Martin
Am 04.07.2010 00:56, schrieb Antoine Pitrou:
On Sun, 04 Jul 2010 00:51:58 +0200 "Martin v. Löwis" <martin@v.loewis.de> wrote:
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.
I think your description already falls into the "advanced user" category. The new-to-mercurial committer should (IMO) use a "what if it still was svn" workflow, which uses hg pull/up/commit/push.
This assumes they are accustomed to SVN. I guess not all people are, although it is certainly a common skill.
I thought we were talking about Python committers specifically. Regards, Martin
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.
If you’re using named branches or bookmarks, there is an easy way to throw away the whole branch. Say you have a clone with branches default, fix8888, fix9008, shlex-unicode (default is clean upstream Python 3.2, the other three are branches you made for bug fixes or features). Now you want to discard shlex-unicode. $ cd .. $ mv cpython cpython.old $ hg clone cpython.old cpython -r default -r fix8888 -r fix9008 $ rm -r cpython.old The new repo will only contain the branches you ask for. Giving all names on the command line may be cumbersome if you’re on a lot of branches at one, but it’s okay for a small number. A small bit of shell scripting can automate that easily (get all branches, remove the one given as argument to the shell function, mv, hg clone, rm). Of course, a branch you wan to abandon can stay in your repo for a while if you don’t want to clean up now. HTH. Regards
Am 04.07.2010 00:59, schrieb "Martin v. Löwis":
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.
Of course, in SVN throwing away committed changes is completely impossible :)
There are extensions to uncommit, but they are discouraged and have limitations.
I wouldn't say that. strip works well and it does so logically, once one understands the DAG. The only thing discouraged is to strip changesets once pushed to the public repo, but that holds as well for getting rid of the changesets by making a new clone without them. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
The other risk with history-editing extensions is that they use the merge and rebase machinery to do their work, so they require a clean working directory. Otherwise you may loose uncommitted changes. Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar. Regards
"Martin v. Löwis" <martin@v.loewis.de> writes:
My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently:
This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch?
IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway).
I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required?
You don't -- it is tempting to think of a "named branch" as a kind of container for changesets, but that metaphor makes people think that you can put changesets "into" a named branch and takes them "out" again. The opposite is in fact true: the changesets induce the named branch. Each changeset has a field in its metadata that names the branch it is on. So if you do hg branch X hg commit -m "Created X branch" then the newly created changeset has branch="X" in its metadata. The X branch has thus been created because of the changeset. If there are no changesets with branch="X" in your repository, then there is no X branch. A named branch is thus more a labeling system -- changesets belonging to the branch can (in principle) be scattered all over the repository. They are normally a connected sub-graph, though, and Mercurial will complain if you try to re-start a branch name. Since the branch name is embedded into the changesets themselves, you cannot changeset it without changing the identities of the changesets. A branch appears in the output of 'hg branches' if there are any open branch heads (a "branch head" is a changeset with no children on the same named branch). Use the 'hg commit --close-branch' command to make a closed branch head. The branch is considered closed when it only has closed branch heads. Summing up, the notion of named branches correspond quite closely to how people model branches in Subversion: if you make your changes in the directory branches/X/, then we say you "work on the X branch". These revisions will always be on that branch. You can delete the branch by deleting the directory from the HEAD revision. The changes remain in the history and even after merging with trunk/, the old revision will of course show that they were made in the branches/X/ directory. Take a look at the bookmarks extension if you want to work with un-named branches (often called anonymous branches) instead. These branches are just a fork in the history graph, but they have no permanent name. The bookmarks gives you a convenient way to refer to them. Without bookmarks you can of course look at 'hg heads' or some other log viewer. http://mercurial.selenic.com/wiki/BookmarksExtension Since Mercurial 1.6, you can push and pull the bookmarks between repositories. They used to be local only, but this is now solved. See the bottom of the wiki page. -- Martin Geisler Mercurial links: http://mercurial.ch/
Am 04.07.2010 13:29, schrieb Éric Araujo:
The other risk with history-editing extensions is that they use the merge and rebase machinery to do their work, so they require a clean working directory. Otherwise you may loose uncommitted changes.
That's true.
Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar.
That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar.
That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage...
Okay, make that “not requiring any third-party Mercurial extension” :) Some extensions are too useful to be left out, and since they’re shipped with Mercurial the cost of using them is null (patchbomb, eol, bookmarks, graphlog, progress, relink, crecord, rebase). MQ is another beast, it’s a new way of using Mercurial for middle or advanced users. Cheers
Am 04.07.2010 13:53, schrieb Éric Araujo:
Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar.
That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage...
Okay, make that “not requiring any third-party Mercurial extension” :)
mq is anything but third-party.
Some extensions are too useful to be left out, and since they’re shipped with Mercurial the cost of using them is null (patchbomb, eol, bookmarks, graphlog, progress, relink, crecord, rebase).
MQ is another beast, it’s a new way of using Mercurial for middle or advanced users.
mq contains the strip command. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Am 04.07.2010 13:37, schrieb Martin Geisler:
"Martin v. Löwis" <martin@v.loewis.de> writes:
My question is basically the same as Terry Reedy's, but I'm going to phrase it a bit differently:
This is perhaps a naive question, but why do you create a second local clone instead of just creating a branch?
IIUC, if you create a named branch, the branch will become globally visible when you push your changes back. I assume people will consider that clutter - it would be sufficient to just push the changes on the branch, along with commit messages, but not the branch itself (which would be only temporary, anyway).
I'm not even sure how you pull changes from one branch into another: can somebody kindly explain the commands that would be required?
You don't -- it is tempting to think of a "named branch" as a kind of container for changesets, but that metaphor makes people think that you can put changesets "into" a named branch and takes them "out" again.
I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be "hg merge <otherbranch>". Subsequently committing the merge (after fixing conflicts) creates a new changeset "on" the current branch. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Not requiring any Mercurial extension to contribute to Python would be a nice policy to lower the entry bar.
That is already defeated by the need for the eol extension (which is now built-in in hg 1.6). Activating mq is something every developer should manage...
Okay, make that “not requiring any third-party Mercurial extension” :)
mq is anything but third-party.
Sorry, I didn’t want to imply that. What I meant was: Since eol is already a requirement, and since extensions provide tremendously useful things, it’s okay to require or recommend some of them. MQ is in another category IMO not because it’s not shipped-with, since it is, but because it makes you think differently that regular Mercurial usage. (Not saying better or worse, just differently, thus a bit more difficult for would-be contributors.)
mq contains the strip command.
Which fits into regular Mercurial usage without requiring any MQ knowledge, agreed. By the way, is eol a requirement for people using Windows tools with limitations only, or for every person that will clone Python? Regards
On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo <merwok@netwok.org> wrote:
By the way, is eol a requirement for people using Windows tools with limitations only, or for every person that will clone Python?
It's designed so that everyone can run it regardless of platform. If someone chooses not to use it and messes up the line endings then the central repository hooks will reject the commit. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be "hg merge <otherbranch>". Subsequently committing the merge (after fixing conflicts) creates a new changeset "on" the current branch.
Indeed, merges are branch-wise operations, not changeset-wise. You need tricks to copy one changeset from a named branch into another one. Copying changesets between a stable branch and a devel branch is easy if the devel history is a strict superset of the stable history. Every changesets landing into stable can then just be pulled into devel. This means no different named branches for stable and devel. Not sure I’m clear enough, I hope Mercurial experts can chime in. Regards
Éric Araujo <merwok@netwok.org> writes:
I'm not sure if I misunderstand Martin's intent, but in principle, if you want to merge one changes (not changesets!) branch into another, all you need to do would be "hg merge <otherbranch>". Subsequently committing the merge (after fixing conflicts) creates a new changeset "on" the current branch.
Indeed, merges are branch-wise operations, not changeset-wise. You need tricks to copy one changeset from a named branch into another one.
You basically need to replay the changes -- the transplant extension can do this for you. This is more or less a wrapper around 'hg export' (gives you a diff) and 'hg import' (applies the diff).
Copying changesets between a stable branch and a devel branch is easy if the devel history is a strict superset of the stable history. Every changesets landing into stable can then just be pulled into devel. This means no different named branches for stable and devel. Not sure I’m clear enough, I hope Mercurial experts can chime in.
It sounds like you are describing how Mercurial itself was developed before we began using named branches. This part of the graph is typical for us then: http://selenic.com/repo/hg/graph/52c5be55af82 Notice the three merges wtih 'crew-stable', which was what we called the clone representing the next stable release. Whenever a bugfix is made, it is immediatedly merged into the 'crew' clone, where normal development takes place. This gives a characteristic flow with two tracks (branches), where one is continuously merged into the other. The two with commit message "Fix typeerror when specifying both --rebase and --pull" (dd1b47e17d7e and aee8455ee8ec) are a typical example of a transplanted changeset: the bug was first fixed in 'crew', but it was then realized that it should also be in the 'crew-stable' repository so that it could be part of the next point release. Today we use a 'stable' branch in addition to the 'default' branch and the graph looks much the same: http://selenic.com/repo/hg/graph/4d3288197717 You'll notice the small labels saying 'stable' on the changesets from that branch -- that is the whole difference. A named branch is made up by the changesets that same the branch name, but the graph itself works the same. The nice thing about our current setup is that I can do hg update stable and the name 'stable' is then interpreted as the tip-most changeset on the stable branch. -- Martin Geisler Mercurial links: http://mercurial.ch/
[Martin Geisler]
You basically need to replay the changes -- the transplant extension can do this for you. This is more or less a wrapper around 'hg export' (gives you a diff) and 'hg import' (applies the diff).
Core developers seem to be okay with svnmerge, so perhaps a familiar-looking command like transplant (with “merges” that are actually replays, and explicit blocking for bookkeeping) will feel right to them.
It sounds like you are describing how Mercurial itself was developed before we began using named branches.
Spot on, sir!
[snip] You'll notice the small labels saying 'stable' on the changesets from that branch -- that is the whole difference.
Thanks for the explanation. The new workflow seems quite good. Regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote:
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.
I think your description already falls into the "advanced user" category. The new-to-mercurial committer should (IMO) use a "what if it still was svn" workflow, which uses hg pull/up/commit/push. That can only work if pushing really has the desired effect, which isn't the case for any of the installations that we operate.
I am not a committer myself, and not really familiar with Mercurial (I know CVS/SVN best, and bzr better). I found the current hg mirror of svn quite useful as a way to work on bugs, review patches, etc. without needing any commit access.
When the test-for-two-weeks installation becomes available, the new-to-hg users will have a chance to learn how to use it without fear of breaking anything. Until then, they should just remain patient.
Experimenting with the mirror *today* without trying to push changes back would give those users a chance to do "familiarization" drills with the majority of mercurial's features, with the exception of the final push. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkwyPKwACgkQ+gerLs4ltQ6zxQCcCRFduUc97jH3g28m/xh3+fTC RtIAniyqilkaNFHS54bW+oF4YXv/cq4l =pdkc -----END PGP SIGNATURE-----
Experimenting with the mirror *today* without trying to push changes back would give those users a chance to do "familiarization" drills with the majority of mercurial's features, with the exception of the final push.
That's true. However, for those users, I'd rather recommend to use hg on an entirely independent project. That worked for me. Regards, Martin
Georg Brandl writes:
I wouldn't say that. strip works well and it does so logically, once one understands the DAG. The only thing discouraged is to strip changesets once pushed to the public repo, but that holds as well for getting rid of the changesets by making a new clone without them.
Actually, neither method of "rewinding" a local repo is especially discouraged, if you know what you're doing. What you mustn't do is strip the changes in the public repo itself (or turn them into unreferencable garbage). Back in the bad old days of git, "push" often had such effects, but with modern versions of any of the dVCSes, public repos are allowed to refuse pushes that would garbage any changesets, and even if they're permitted, you need to use a --force option to push. There's nothing wrong with stripping your local repo(s), even if the stripped changes have already been pushed to the public repo. I would say it's unusual for most people to want to strip publicly available changesets, but after all, you just end up with an out-of-date repo, which is exactly what Mercurial is all about handling. Ie, it is *normal* to have an out-of-date repo locally when there are other active committers; it's just unusual to intentionally strip. But the consequences are the same. As with any out-of-date repo, you will need to merge before pushing. New users probably shouldn't do it to excess, because of the possibility of exposing yourself to a difficult merge. But the flip side is that new users probably want to update from the public repo before doing significant work for exactly the same reasons.
On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
After the switch, hg.python.org/cpython will be the official repo, and code.python.org/hg will probably be closed.
Why this transition is not described in PEP?
Because it's not a transition. It's a mirror. It was put in place before the hg migration plan was accepted, IIRC.
Where is this migration plan then if it is not in PEP?
How code.python.org/hg is synchronized with Subversion?
What does your question mean exactly? It's a mirror (well, a set of mirrors) and is synchronized roughly every 5 minutes.
Method. Software used, which parameters are set for it, how to repeat the process?
Why it is not possible to leave code.python.org/hg as is in slave mode and then realtime replication is ready just switch master/slave over?
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).
That would be nice to hear about in more detail. As I understand there is no place where it is described. I already see +1 from Fred Drake and another +1 from Steve Holden down the thread. However, Antoine Pitrou, Dirkjan Ochtman and Jesse Noller object. They afraid that contributors won't survive low-level details about Mercurial migration. I'd say there a plenty of ways isolate them and at the same time satisfy "Mercurial aficionados" either on the same page or in different places. On Fri, Jul 2, 2010 at 4:06 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
There is no reason at this point to suppose the transition can't be complete by the end of summer. However, as always, the devil is in the details, and one of them may be a showstopper. We'll just have to see about that.
The transition can be complete in a few minutes. The question is how good it will be. As there are no plan, no roadmap, no status - it is hard to judge if it is feasible at all. Ok. Given that nobody is able/willing to say anything more - I've gathered all your feedback concerning current status of Mercurial migration on this Wave - https://wave.google.com/wave/waveref/googlewave.com/w+4_fnAVHwA I hope you will find the time to enhance it with more info so not contributors proficient with Mercurial could help to speed up the transition. -- anatoly t.
On Tue, Jul 6, 2010 at 7:47 PM, anatoly techtonik <techtonik@gmail.com> wrote:
On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
After the switch, hg.python.org/cpython will be the official repo, and code.python.org/hg will probably be closed.
Why this transition is not described in PEP?
Because it's not a transition. It's a mirror. It was put in place before the hg migration plan was accepted, IIRC.
Where is this migration plan then if it is not in PEP?
How code.python.org/hg is synchronized with Subversion?
What does your question mean exactly? It's a mirror (well, a set of mirrors) and is synchronized roughly every 5 minutes.
Method. Software used, which parameters are set for it, how to repeat the process?
Why it is not possible to leave code.python.org/hg as is in slave mode and then realtime replication is ready just switch master/slave over?
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).
That would be nice to hear about in more detail. As I understand there is no place where it is described. I already see +1 from Fred Drake and another +1 from Steve Holden down the thread.
However, Antoine Pitrou, Dirkjan Ochtman and Jesse Noller object. They afraid that contributors won't survive low-level details about Mercurial migration. I'd say there a plenty of ways isolate them and at the same time satisfy "Mercurial aficionados" either on the same page or in different places.
No, I don't need you misrepresenting anything I've said Anatoly - I said there's no need to maintain SVN alongside mercurial after we convert, and doing so is silly. I maintain that once we convert, we very happily stay converted, and drop official "other" mirrors unless other volunteers step up to maintain them. I have no problem with additional documentation should people wish to volunteer to write it. We do not work for you Anatoly.
On Fri, Jul 2, 2010 at 4:06 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
There is no reason at this point to suppose the transition can't be complete by the end of summer. However, as always, the devil is in the details, and one of them may be a showstopper. We'll just have to see about that.
The transition can be complete in a few minutes. The question is how good it will be. As there are no plan, no roadmap, no status - it is hard to judge if it is feasible at all.
No. There is no question except in your mind. We all have a rough idea of the status, modulo the PEPs being updated. It is also perfectly feasible. I would love it, and offer you a christmas card if you could drop the hyperbole and misrepresentation.
Ok. Given that nobody is able/willing to say anything more - I've gathered all your feedback concerning current status of Mercurial migration on this Wave - https://wave.google.com/wave/waveref/googlewave.com/w+4_fnAVHwA I hope you will find the time to enhance it with more info so not contributors proficient with Mercurial could help to speed up the transition.
While the summary is nice; your wave entry has nothing to do with the mercurial transition, if you want to help, please ask someone to take on an open task, or volunteer to write/accentuate the PEPs, or help with documentation for post-migration workflow. Your contributions can be effective and useful, rather than noisemaking and abrasive. The mercurial transition will occur, barring someone directly involved finding show-stopping reasons otherwise, with or without you. The decision was made some time ago, and despite your recent noisemaking, will continue on. jesse
Because it's not a transition. It's a mirror. It was put in place before the hg migration plan was accepted, IIRC. Where is this migration plan then if it is not in PEP?
The “hg migration plan” is PEP 385. It means moving from svn.python.org to hg.python.org. It is not possible to make code.python.org/hg a mirror of the future official hg repo (a quick search on the hgbook or the Mercurial wiki will tell you how changeset hashes work). The code.p.o/hg repo was a simple read-only mirror provided as a service to the community. Now that the official repo will be a new, clean Mercurial repo, the current mirror will become redundant and will probably be closed. People using that mirror to follow cpython development and/or propose patches will just redo a clone and rebase their patches.
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). That would be nice to hear about in more detail. As I understand there is no place where it is described.
The layout of the future official repo is in PEP 385. The layout of the old mirror can be understood by looking at the Web interface (one repo per svn maintenance branch, etc.)
The transition can be complete in a few minutes. The question is how good it will be. As there are no plan, no roadmap, no status
The transition is not just a command to be run, it includes discussion and writing tools before that, and feedback and support after that. What we call transition is the whole process. People have worked and are still working on the PEP, on the repo, on the policy and on the documentation, and it is unfair not to acknowledge that work and say there is no plan. Regards
On Wed, Jul 7, 2010 at 01:47, anatoly techtonik <techtonik@gmail.com> wrote:
That would be nice to hear about in more detail. As I understand there is no place where it is described. I already see +1 from Fred Drake and another +1 from Steve Holden down the thread.
However, Antoine Pitrou, Dirkjan Ochtman and Jesse Noller object. They afraid that contributors won't survive low-level details about Mercurial migration.
I'm happy to answer direct questions about the transition process I have in mind (and mostly written down in the PEP), or the resulting hg repository. I think the PEP has some details about what I think constitutes a good conversion. If there are things that Fred or Steve miss from that discussion, I'd be happy to add to the PEP. Cheers, Dirkjan
participants (26)
-
"Martin v. Löwis" -
anatoly techtonik -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
C. Titus Brown -
Dan Buch -
Daniel Stutzbach -
Dirkjan Ochtman -
Doug Hellmann -
Eli Bendersky -
Fred Drake -
Georg Brandl -
Jesse Noller -
Martin Geisler -
Nick Coghlan -
Paul Moore -
R. David Murray -
Stephen J. Turnbull -
Steve Holden -
Terry Reedy -
Thomas Jollans -
Tim Delaney -
Tim Golden -
Tres Seaver -
Éric Araujo