Re: [Python-Dev] Mercurial migration readiness

On Wed, Jul 7, 2010 at 01:47, anatoly techtonik 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

Re: [Python-Dev] Mercurial migration readiness

>> 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 co

Re: [Python-Dev] Mercurial migration readiness

On Tue, Jul 6, 2010 at 7:47 PM, anatoly techtonik wrote: > On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou 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?

Re: [Python-Dev] Mercurial migration readiness

On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou 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 p

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

> 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 a

Re: [Python-Dev] Mercurial migration readiness

-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 f

Re: [Python-Dev] Mercurial migration readiness

[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 com

Re: [Python-Dev] Mercurial migration readiness

Éric Araujo 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 ". Subsequently >> committing the merge (after fixing conflicts) creates a new changeset >>

Re: [Python-Dev] Mercurial migration readiness

> 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 ". Subsequently committing > the merge (after fixing conflicts) creates a new changeset "on" the current > branch.

Re: [Python-Dev] Mercurial migration readiness

On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo 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

Re: [Python-Dev] Mercurial migration readiness

Am 04.07.2010 13:37, schrieb Martin Geisler: > "Martin v. Löwis" 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

Re: [Python-Dev] Mercurial migration readiness

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... >> >> Oka

Re: [Python-Dev] Mercurial migration readiness

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 de

Re: [Python-Dev] Mercurial migration readiness

"Martin v. Löwis" 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 b

Re: [Python-Dev] Mercurial migration readiness

>> 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 “no

Re: [Python-Dev] Mercurial migration readiness

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 exten

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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,

Re: [Python-Dev] Mercurial migration readiness

> 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

Re: [Python-Dev] Mercurial migration readiness

Am 04.07.2010 00:56, schrieb Antoine Pitrou: > On Sun, 04 Jul 2010 00:51:58 +0200 > "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

Re: [Python-Dev] Mercurial migration readiness

> 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 w

Re: [Python-Dev] Mercurial migration readiness

> 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 pr

Re: [Python-Dev] Mercurial migration readiness

On Sun, 04 Jul 2010 00:51:58 +0200 "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 w

Re: [Python-Dev] Mercurial migration readiness

>>> 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

Re: [Python-Dev] Mercurial migration readiness

On Sat, Jul 3, 2010 at 11:36 AM, Tres Seaver 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 pyt

Re: [Python-Dev] Mercurial migration readiness

-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 discar

Re: [Python-Dev] Mercurial migration readiness

On Sat, 03 Jul 2010 14:16:08 -0400 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?) Filling less of your disk, actually, since local clones use hardlinks. Also, pulling less

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

-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 wrote: >>> The two sets of repositories use different conversion tools and rules. >>> They have nothing in common (different changeset

Re: [Python-Dev] Mercurial migration readiness

-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-committ

Re: [Python-Dev] Mercurial migration readiness

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 > > htt

Re: [Python-Dev] Mercurial migration readiness

> > > 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

Re: [Python-Dev] Mercurial migration readiness

> 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 final

Re: [Python-Dev] Mercurial migration readiness

Am 02.07.2010 15:09, schrieb Fred Drake: > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou 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 t

Re: [Python-Dev] Mercurial migration readiness

> 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

Re: [Python-Dev] Mercurial migration readiness

"Stephen J. Turnbull" 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

Re: [Python-Dev] Mercurial migration readiness

Antoine Pitrou wrote: > On Fri, 02 Jul 2010 12:55:56 -0400 > Steve Holden wrote: >> Fred Drake wrote: >>> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote: The two sets of repositories use different conversion tools and rules. They have nothing in common (different changeset IDs, di

Re: [Python-Dev] Mercurial migration readiness

On Fri, Jul 2, 2010 at 1:12 PM, Antoine Pitrou wrote: > On Fri, 02 Jul 2010 12:55:56 -0400 > Steve Holden wrote: >> Fred Drake wrote: >> > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote: >> >> The two sets of repositories use different conversion tools and rules. >> >> They have nothing in

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

Georg Brandl wrote: > Am 02.07.2010 16:17, schrieb anatoly techtonik: >> On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl 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 conversi

Re: [Python-Dev] Mercurial migration readiness

On Fri, 02 Jul 2010 12:55:56 -0400 Steve Holden wrote: > Fred Drake wrote: > > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote: > >> The two sets of repositories use different conversion tools and rules. > >> They have nothing in common (different changeset IDs, different > >> metadata, diff

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

Fred Drake wrote: > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou 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 d

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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 Mercu

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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 mi

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

Am 02.07.2010 16:17, schrieb anatoly techtonik: > On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

-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 wrote: So, if I understand correctly - there are no Mercurial mirrors for testing at the moment, >>> There are repositorie

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Fri, Jul 2, 2010 at 10:17 AM, anatoly techtonik wrote: > On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl 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 proce

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Fri, Jul 2, 2010 at 16:17, anatoly techtonik 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl 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

Re: [Python-Dev] Mercurial migration readiness

On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou 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 s

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

Am 02.07.2010 15:48, schrieb anatoly techtonik: > On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl 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 re

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl 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 p

Re: [Python-Dev] Mercurial migration readiness

On Fri, 2 Jul 2010 09:09:48 -0400 Fred Drake wrote: > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou 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).

Re: [Python-Dev] Mercurial migration readiness

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 suggest

Re: [Python-Dev] Mercurial migration readiness

On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou 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, includi

Re: [Python-Dev] Mercurial migration readiness

On Fri, 2 Jul 2010 15:22:44 +0300 anatoly techtonik wrote: > On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo 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 swit

Re: [Python-Dev] Mercurial migration readiness

On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo 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

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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 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 >>> off

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

Am 02.07.2010 01:05, schrieb Antoine Pitrou: > On Thu, 1 Jul 2010 15:26:12 -0700 > Brett Cannon 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

Am 02.07.2010 09:27, schrieb anatoly techtonik: > On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller 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 t

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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 > > wrote: >> >> 4. Even if I make patch in my Mercurial clone - you still can't pull >> it and I have to

Re: [Python-Dev] Mercurial migration readiness

On 02/07/2010 08:25, Dirkjan Ochtman wrote: On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull 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 ma

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller 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 unde

Re: [Python-Dev] Mercurial migration readiness

> 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 inst

[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote: >On Thu, Jul 1, 2010 at 15:07, Barry Warsaw 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On 2 July 2010 09:08, Tim Delaney wrote: > On 2 July 2010 08:07, Barry Warsaw 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 a

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On 2 July 2010 08:07, Barry Warsaw 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 fro

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, 1 Jul 2010 15:26:12 -0700 Brett Cannon 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.

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 15:07, Barry Warsaw wrote: > On Jul 01, 2010, at 10:57 PM, Paul Moore wrote: > >>On 1 July 2010 20:58, Brett Cannon 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 ot

Re: [Python-Dev] Mercurial migration readiness

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 alrea

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Jul 01, 2010, at 10:57 PM, Paul Moore wrote: >On 1 July 2010 20:58, Brett Cannon 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 any

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On 1 July 2010 20:58, Brett Cannon 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 sa

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote: On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik 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 reposito

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

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 w

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 07:31, R. David Murray wrote: > On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman > wrote: >> On Thu, Jul 1, 2010 at 14:52, anatoly techtonik wrote: >> > Primary concern is that will happen with central Subversion >> > repository. There are a plenty of private tools and

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 8:52 AM, anatoly techtonik 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote: > On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik 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 h

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach 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 centr

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach 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 o

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman wrote: > On Thu, Jul 1, 2010 at 14:52, anatoly techtonik 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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik 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 se

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

On Thu, Jul 1, 2010 at 14:52, anatoly techtonik 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

[Python-Dev] 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