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
On Wed, Jul 7, 2010 at 01:47, anatoly techtonik techto...@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,
On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou solip...@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
On Tue, Jul 6, 2010 at 7:47 PM, anatoly techtonik techto...@gmail.com wrote:
On Fri, Jul 2, 2010 at 3:34 PM, Antoine Pitrou solip...@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
-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
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
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
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,
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
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
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
Martin v. Löwis mar...@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,
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
Am 04.07.2010 13:37, schrieb Martin Geisler:
Martin v. Löwis mar...@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
On Sun, Jul 4, 2010 at 10:41 PM, Éric Araujo mer...@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
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
Éric Araujo mer...@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
[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
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
-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
-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 solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different
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
On Sat, 03 Jul 2010 14:16:08 -0400
Terry Reedy tjre...@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,
-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
On Sat, Jul 3, 2010 at 11:36 AM, Tres Seaver tsea...@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:
$
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
On Sun, 04 Jul 2010 00:51:58 +0200
Martin v. Löwis mar...@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
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
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
Am 04.07.2010 00:56, schrieb Antoine Pitrou:
On Sun, 04 Jul 2010 00:51:58 +0200
Martin v. Löwis mar...@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
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
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller jnol...@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.
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull step...@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
On 02/07/2010 08:25, Dirkjan Ochtman wrote:
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbullstep...@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
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 techto...@gmail.com
mailto:techto...@gmail.com wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull
it and I
Am 02.07.2010 09:27, schrieb anatoly techtonik:
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller jnol...@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
Am 02.07.2010 01:05, schrieb Antoine Pitrou:
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon br...@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
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 jnol...@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
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
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo mer...@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
On Fri, 2 Jul 2010 15:22:44 +0300
anatoly techtonik techto...@gmail.com wrote:
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo mer...@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
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@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
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
On Fri, 2 Jul 2010 09:09:48 -0400
Fred Drake fdr...@acm.org wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs, different
metadata,
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl g.bra...@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
Am 02.07.2010 15:48, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl g.bra...@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
On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou solip...@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.
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@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
On Fri, Jul 2, 2010 at 16:17, anatoly techtonik techto...@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.
On Fri, Jul 2, 2010 at 10:17 AM, anatoly techtonik techto...@gmail.com wrote:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@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
-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.bra...@gmx.net wrote:
So, if I understand correctly - there are no Mercurial mirrors for
testing at the moment,
There are
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@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
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
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
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@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
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*.
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs,
Georg Brandl wrote:
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@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
On Fri, Jul 2, 2010 at 1:12 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different
Antoine Pitrou wrote:
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common
Stephen J. Turnbull step...@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
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
Am 02.07.2010 15:09, schrieb Fred Drake:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@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).
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
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
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
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik techto...@gmail.comwrote:
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
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik techto...@gmail.com wrote:
Primary concern is that will happen with central Subversion
repository. There are a plenty of private tools and automated scripts
that
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
dan...@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
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
dan...@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
On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik techto...@gmail.comwrote:
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
On Thu, Jul 1, 2010 at 8:52 AM, anatoly techtonik techto...@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
On Thu, Jul 1, 2010 at 07:31, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman dirk...@ochtman.nl
wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik techto...@gmail.com wrote:
Primary concern is that will happen with central Subversion
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
On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik
techto...@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
On 1 July 2010 20:58, Brett Cannon br...@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
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon br...@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
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
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw ba...@python.org wrote:
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon br...@python.org wrote:
Here is a *really* quick-and-dirty approach for non-committers to
create a patch they can submit. This is not
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon br...@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
On 2 July 2010 08:07, Barry Warsaw ba...@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
On 2 July 2010 09:08, Tim Delaney timothy.c.dela...@gmail.com wrote:
On 2 July 2010 08:07, Barry Warsaw ba...@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
On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote:
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw ba...@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
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
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
85 matches
Mail list logo
