Barry Warsaw wrote:
On Jul 3, 2009, at 5:00 PM, Martin v. Löwis wrote:
I'm -1 on calling it sys.revision, as this makes it difficult to
tell what the actual versioning system was, and hence how the
data should be interpreted. It will already be a problem for 2.6,
when 2.6.3 will currently
On Jul 3, 2009, at 6:15 PM, Martin v. Löwis wrote:
I'm fine with that plan - but the original problem remains. We will
surely release 2.6.4 at some point, and it will have a different
version
identification (based on hg rev ids).
So those existing applications (which are probably few) will
On 4/07/2009 12:04 AM, Nick Coghlan wrote:
However, I expect that would still be painful to work with for Windows
developers, even if it prevented any line ending problems from making
their way into the main repository. I believe that is where the
win32text extensions can help. Looking at the
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 15:31, Mark Hammondmhamm...@skippinet.com.au wrote:
So we must work without effective EOL support? I fear we will end up like
the mozilla hg repo with some files in windows line endings and some with
linux. While my editing
Doesn't Mercurial support an Subversion bridge? Would it be possible to
provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6,
and 3.1? If so, then the release managers would simply have to cut
their releases from the svn copy instead of the hg master. /All/ other
work
Mark Hammond wrote:
On 4/07/2009 12:04 AM, Nick Coghlan wrote:
The big problem I have with win32text is that the rules are not
versioned, meaning we will rely on every (windows only?) developer
manually enabling the win32text extension, then manually adding these
rules to an unversioned hgrc
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
As long as the difference between \r\n- and \n-based files is clear
and can be reasoned about, I don't see why having some of both (I'm
assuming an overwhelming majority will have one, and only a few the
other) is a big problem. But feel free to
Brett Cannon wrote:
On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman dirk...@ochtman.nl
mailto:dirk...@ochtman.nl wrote:
Actually, I currently have /cpython to also make CPython less special
among it's peers, but that idea was met with some resistance on
#python-dev.
Don't worry
On 4/07/2009 11:20 AM, Nick Coghlan wrote:
I didn't realise Mercurial didn't have a way for a repository to provide
versioned extension settings, but in this case I think using our own
server side hook can deal with the problem (either adding it to the
existing whitespace hook that checks for
Martin v. Löwis wrote:
I would drop the roundup integration from the things that need to
be done pre-migration - there currently is no svn integration, so
not having it for hg is not a step backwards.
That's not quite true - the tracker turns text like r64537 into a link
to the appropriate
Mark Hammond wrote:
This *appears* to be correct at first glance, but in practice it doesn't
interact well with wildcards specifications - particularly
'**=cleverencode'. I started a thread on the ML and submitted a patch a
few months ago to fix this and it was accepted, but sadly it seemed
Dirkjan Ochtman writes:
On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbullstep...@xemacs.org wrote:
I'll have to try them again now that 1.3 is out, but I found Mercurial
named branches fundamentally unsuited to release management.
Can you explain why, please? It's not clear from what
Nick Coghlan wrote:
Martin v. Löwis wrote:
I would drop the roundup integration from the things that need to
be done pre-migration - there currently is no svn integration, so
not having it for hg is not a step backwards.
That's not quite true - the tracker turns text like r64537 into a link
On Sat, 4 Jul 2009 04:22:57 am Terry Reedy wrote:
I would very much like the 'k' dropped from the py3 name. It was a
funny joke when py3 was vaporware, now it is excess baggage which
only puzzles non-insiders and newcomers.
+1
Some day we'll be using Python3.7 and wondering what the k means.
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
...
I think there needs to be a solid answer in place for these use cases
before the actual migration to Mercurial takes place. A hand-waving use
win32text isn't enough - it needs to be use win32text with these exact
settings (with server side hook
Nick Coghlan writes:
I'm not clear on the rationale for the explicit CRLF line ending on the
email test message, but I would guess it is to ensure that the email
module can handle CRLF line endings correctly regardless of platform.
IIRC, that's just the standard for text email. Lines must
At 12:20 PM 7/4/2009 +0900, Stephen J. Turnbull wrote:
IME, Mercurial strongly encourages a non-branching style. Although I
can't fully explain in concrete terms what makes me feel that way,
it's certainly consistent with your own inclination to advise subset
branches. Part of it comes from
Martin v. Löwis wrote:
Ah, right. That must be done, of course (although I suppose there is
little hope to have the existing references continue to work).
I'd guess that the only way to keep those functional is to keep
svn.python.org around in read-only mode.
Although I'm not entirely sure
P.J. Eby writes:
Wouldn't the simple thing to do in Mercurial, just be to use
different repositories for long-lived branches? I mean, if you're
not merging them that much anyway, what's the point?
I basically agree with that, and so does Dirkjan, I think. I'm not
sure why he brought up
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
- First of all, I've got the basic conversion down, I've done it a few
times now, with progressively better results.
2009/7/2 Dirkjan Ochtman dirk...@ochtman.nl:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
Thanks very much for working on this, Dirkjan. It may seem rather
On 3/07/2009 6:42 AM, Dirkjan Ochtman wrote:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
Although this has come up in the past, I don't recall a resolution.
2009/6/6 Mark Hammond skippy.hamm...@gmail.com:
Paul Moore wrote:
2009/6/5 Nick Coghlan ncogh...@gmail.com:
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Yes, it certainly seems that way.
Except it isn't a binary file - it's a text file with CRLF line endings.
Why
2009/6/5 Nick Coghlan ncogh...@gmail.com:
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Yes, it certainly seems that way.
Except it isn't a binary file - it's
Paul Moore wrote:
2009/6/5 Nick Coghlan ncogh...@gmail.com:
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Yes, it certainly seems that way.
Except it isn't a
I just wanted to share my experience with the mercurial checkout. I cloned
http://code.python.org/hg/branches/py3k to continue work on
http://bugs.python.org/issue1578269 but I found that when I click on
PC/VS8.0/pcbuild.sln, nothing happens.
This appears to be due to a bug/limitation in
On Thu, Jun 04, 2009 at 09:02:53AM -0400, Jason R. Coombs wrote:
It seems that within the hg repository, everything has been converted to LF
for line endings. I suspect this is because HG provides no integrated
support for line-ending conversions and because the hg to svn bridge is
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs jar...@jaraco.com wrote:
I wanted to share this with the community in case anyone else runs into this
issue. Also, if there's a recommended procedure for addressing this issue
(and others that might arise due to non-native line endings), I'd be
On Thu, 4 Jun 2009 at 17:30, Oleg Broytmann wrote:
On Thu, Jun 04, 2009 at 09:02:53AM -0400, Jason R. Coombs wrote:
It seems that within the hg repository, everything has been converted to LF for
line endings. I suspect this is because HG provides no integrated support for
line-ending
On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray rdmur...@bitdance.com wrote:
The above statement seems like a really odd design choice, with the
potential for causing considerable developer coordination headaches.
Any Mercurial boffins want to talk about how this works in practice?
I'm
2009/6/4 Dirkjan Ochtman dirk...@ochtman.nl:
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs jar...@jaraco.com wrote:
I wanted to share this with the community in case anyone else runs into this
issue. Also, if there's a recommended procedure for addressing this issue
(and others that might
On Thu, Jun 04, 2009 at 03:20:56PM +0100, Paul Moore wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Subversion has a built-in notion of eol-conversion (don't know if it was
used
On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore p.f.mo...@gmail.com wrote:
Silly question, but given that Mercurial itself does *no* conversion,
and CRLF is the only valid form for that file, why shouldn't the file
be checked into the repository with CRLF endings, and that's the end
of it (apart
Martin v. Löwis wrote:
Nick Coghlan wrote:
Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Martin may be able to provide a better list of names based on the
checkin name-SSH public key
On Tue, Apr 7, 2009 at 00:05, Martin v. Löwis mar...@v.loewis.de wrote:
I think the identification in the SSH keys is useless. It contains
strings like loe...@mira or ncogh...@uberwald, or even multiple
of them (ba...@wooz, ba...@resist, ...).
Right, so we'll put up the author map somewhere
On Tue, Apr 7, 2009 at 2:03 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Alexandre Vassalotti writes:
This makes me remember that we will have to decide how we will
reorganize our workflow. For this, we can either be conservative and
keep the current CVS-style development
On Tue, Apr 7, 2009 at 04:25, Steve Holden st...@holdenweb.com wrote:
I would remind you all that it's *very* necessary to make sure that
whatever finds its way into released code is indeed covered by
contributor agreements. The PSF (as the guardian of the IP) has to
ensure this, and so we
Dirkjan Ochtman dirk...@ochtman.nl writes:
Right. It's basically Name Lastname email -- we can verify that
in a hook.
Remembering, of course, that full names don't follow any template
(especially not first-name last-name). The person's full name must be
treated as free-form text, since there's
On Tue, Apr 7, 2009 at 08:25, Ben Finney ben+pyt...@benfinney.id.au wrote:
Remembering, of course, that full names don't follow any template
(especially not first-name last-name). The person's full name must be
treated as free-form text, since there's no format common to all.
Of course, unless
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano st...@pearwood.info wrote:
Perhaps you should ask Aahz what he thinks about being forced to provide
two names before being allowed to contribute.
Huh? The contributor's agreement list would presumably include real
names only (so Aahz is out of
On Tue, 7 Apr 2009 04:30:10 pm Dirkjan Ochtman wrote:
On Tue, Apr 7, 2009 at 08:25, Ben Finney ben+pyt...@benfinney.id.au
wrote:
Remembering, of course, that full names don't follow any template
(especially not first-name last-name). The person's full name must
be treated as free-form
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote:
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano st...@pearwood.info wrote:
Perhaps you should ask Aahz what he thinks about being forced to provide
two names before being allowed to contribute.
Thanks for speaking up! I'm not sure I would have
On Tue, Apr 7, 2009 at 16:29, Aahz a...@pythoncraft.com wrote:
What you apparently are unaware of is that Aahz is in fact my full
legal name. (Which was clearly the point of Steven's post since he knows
that Teller also has only one legal name -- it's not common, but we do
exist.)
Ah, sorry
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote:
On Tue, Apr 7, 2009 at 16:29, Aahz a...@pythoncraft.com wrote:
What you apparently are unaware of is that Aahz is in fact my full
legal name. (Which was clearly the point of Steven's post since he knows
that Teller also has only one legal name --
Ben is correct: you can't assume that contributors will have both a
first name and a last name, or that a first name and last name is
sufficient to legally identify them. Those from Spanish and Portuguese
cultures usually have two family names as well as a personal name;
people from
Dirkjan Ochtman wrote:
One of the nicer features of Mercurial/DVCSs, in my experience, is
that non-committers get to keep the credit on their patches. That
means that it's impossible to enforce a policy more extensive than
some basic checks (such as the format above). Unless we keep a list of
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz aja...@gmail.com wrote:
BTW, keep in mind some people will prefer to submit diff-generated,
non-hg patches. IMO, this use case should be supported before the
rich-patch one.
Sure, that will be in the PEP as well (and it's quite simple).
On Mon, Apr 6, 2009 at 00:48, Mark Hammond skippy.hamm...@gmail.com wrote:
Just to be clear, what input would you like on that map?
Review of email addresses, pointers to names/email addresses for the
usernames I don't have anything for yet. Also, there's a few commented
question marks, it would
On Mon, Apr 6, 2009 at 04:27, s...@pobox.com wrote:
Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)?
Sure, if we're doing cloned branches. But then someone will also need
to clone 2.5, and maybe 2.4. The point is, as long as it's a constant
factor and not an order of
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti
alexan...@peadrop.com wrote:
But that won't work if people who are not core developers submit us
patch bundle to import. And maintaining a such white-list sounds to me
more burdensome than necessary.
Well, if you need contributors to sign a
Alexandre Vassalotti alexandre at peadrop.com writes:
If I recall correctly, only ssh clients can request compression to the
server—in other words, the server cannot forces the clients to use
compression, but merely allow them use it.
See the man page for sshd_config and ssh_config for the
Martin v. Löwis martin at v.loewis.de writes:
Is it possible to branch from a subdirectory? For the different VMs
stuff, it's rather desirable to have a branch of the test suite, and
the perhaps the standard library, than extracting it from the source.
You can only branch the whole repository.
Alexandre Vassalotti alexandre at peadrop.com writes:
With Mercurial, we will need to add support for server-side clone
ourselves. There's few ways to provide this feature. We give Unix user
accounts to all core developers and let developers manages their
private branches directly on the
Dirkjan Ochtman wrote:
On 05/04/2009 20:29, Martin v. Löwis wrote:
FYI: this is the list of hooks currently employed:
- pre: check whitespace
- post: mail python-checkins
inform regular buildbot
inform community buildbot
trigger website rebuild if a PEP was
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy p...@freehackers.org wrote:
One question: if somebody pushes a changeset with 3 commits, will the
pre and post hooks be applied on all of the commits, or only on the
final commit ?
If this is applied on every commit, then you have no way to fix a
Daniel (ajax) Diniz wrote:
Martin v. Löwis wrote:
I think it would be a good idea to host a temporary svn mirrors for
developers who accesses their VCS via an IDE. Although, I am sure
anymore if supporting these developers (if there are any) would worth
the trouble. So, think of this as
On Mon, Apr 6, 2009 at 11:14, Philippe Fremy p...@freehackers.org wrote:
This is a problem I have with my daily usage of mercurial. It's supposed
to be great to work offline and to commit your intermediate versions
before it's fully working but if you do that, all those intermediate non
Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Martin may be able to provide a better list of names based on the
checkin name-SSH public key mapping in the SVN setup.
(e.g. I believe my SVN
Dirkjan Ochtman wrote:
Another thing that I discussed with Georg last night would be a setup
where changesets get pushed to a gateway repo that runs the tests and
only pushes to an official repo if everything's still green. That
should probably be a topic discussed separately, though.
That
Nick Coghlan wrote:
Dirkjan Ochtman wrote:
Another thing that I discussed with Georg last night would be a setup
where changesets get pushed to a gateway repo that runs the tests and
only pushes to an official repo if everything's still green. That
should probably be a topic discussed
Alexandre Vassalotti wrote:
On Mon, Apr 6, 2009 at 12:20 AM, Aahz a...@pythoncraft.com wrote:
How difficult would it be to change the decision later? That is, how
about starting with a CVS-style system and maybe switch to kernel-style
once people get comfortable with Hg?
I believe it would
Dirkjan Ochtman wrote:
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy p...@freehackers.org wrote:
One question: if somebody pushes a changeset with 3 commits, will the
pre and post hooks be applied on all of the commits, or only on the
final commit ?
If this is applied on every commit, then
On Mon, Apr 6, 2009 at 13:55, Michael Foord fuzzy...@voidspace.org.uk wrote:
Gated checkins can work fine but can also have many problems. For example if
we have a spuriously failing test then if you are working on an unrelated
issue it will be entirely up to chance as to whether you can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 6, 2009, at 7:55 AM, Michael Foord wrote:
Gated checkins can work fine but can also have many problems. For
example if we have a spuriously failing test then if you are working
on an unrelated issue it will be entirely up to chance as to
Nick Coghlan ncogh...@gmail.com writes:
My guess was that Bazaar anchored the centralised end of the DVCS
scale by letting users avoid caring about the underlying acyclic
graph
[…]
That makes Bazaar easy to pitch conceptually to someone like me
(you can use it just like you use SVN, only
Ben Finney wrote:
Nick Coghlan ncogh...@gmail.com writes:
Mercurial appears to best allow the sales pitch to be tailored to
the target audience (in this case, a group including a lot of people
with a background predominantly involving centralised version
control tools).
I don't follow.
Nick Coghlan wrote:
Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Martin may be able to provide a better list of names based on the
checkin name-SSH public key mapping in the SVN setup.
Dirkjan Ochtman wrote:
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti
alexan...@peadrop.com wrote:
But that won't work if people who are not core developers submit us
patch bundle to import. And maintaining a such white-list sounds to me
more burdensome than necessary.
Well, if you
Alexandre Vassalotti writes:
This makes me remember that we will have to decide how we will
reorganize our workflow. For this, we can either be conservative and
keep the current CVS-style development workflow--i.e., a few main
repositories where all developers can commit to.
That was the
Off the top of my head, the following is needed for a successful migration:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I see that this has four branches. What about all the other branches?
Will they be converted, or not? What about the stuff outside
On Sun, Apr 5, 2009 at 6:06 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Off the top of my head, the following is needed for a successful migration:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I see that this has four branches. What about all the
Not sure what this means. There is currently svn support insofar as the
tracker can format rNNN references into ViewCVS links; this should be
updated if possible (removed if not). There would also be a possibility
to auto-close issues from the commit messages. This is not done
currently, so
On 05/04/2009 07:55, Alexandre Vassalotti wrote:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good. We'll also have to decide on named
branches vs.
On 05/04/2009 02:44, Martin v. Löwis wrote:
I'm personally happy letting you do that (although I do wonder who would
then be in charge of the Mercurial installation in the long run, the way
I have been in charge of the subversion installation).
I'd be happy to commit to that for the
On 05/04/2009 11:06, Martin v. Löwis wrote:
In particular, the Stackless people have requested that they move along
with what core Python does, so their code should also be converted.
I'd be interested to hear if they want all of their stuff converted, or
just the mainline/trunk of what is
Alexandre Vassalotti alexandre at peadrop.com writes:
Off the top of my head, the following is needed for a successful migration:
There's also the issue of how we adapt the current workflow of svnmerging
between branches when we want to back- or forward-port stuff. In particular,
tracking of
On 05/04/2009 12:27, Antoine Pitrou wrote:
There's also the issue of how we adapt the current workflow of svnmerging
between branches when we want to back- or forward-port stuff. In particular,
tracking of already done or blocked backports.
Right. The canonical way to do that with Mercurial is
Dirkjan Ochtman dirkjan at ochtman.nl writes:
Right. The canonical way to do that with Mercurial is to commit patches
against the oldest branch where they should be applied, so that every
stable branch is a strict subset of every less stable branch.
It doesn't work between py3k and trunk,
On 05/04/2009 13:00, Antoine Pitrou wrote:
Transplant or export/import have the right semantics IMO, but we lose the
tracking that's built in svnmerge. Perhaps a new hg extension? ;)
(the missing functionality is to store the list of transplanted or blocked
changesets in a .hgXXX file (storing
Dirkjan Ochtman schrieb:
On 05/04/2009 12:27, Antoine Pitrou wrote:
There's also the issue of how we adapt the current workflow of svnmerging
between branches when we want to back- or forward-port stuff. In particular,
tracking of already done or blocked backports.
Right. The canonical way
On Sun, Apr 5, 2009 at 5:06 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Off the top of my head, the following is needed for a successful migration:
- Verify that the repository at http://code.python.org/hg/ is
properly converted.
I see that this has four branches. What about all the
2009/4/5 Alexandre Vassalotti alexan...@peadrop.com:
Off the top of my head, the following is needed for a successful migration:
...
- Update the release.py script.
I'll do this.
--
Regards,
Benjamin
___
Python-Dev mailing list
2009/4/5 Dirkjan Ochtman dirk...@ochtman.nl:
On 05/04/2009 11:06, Martin v. Löwis wrote:
- come up with a strategy for /external (also relevant for
the buildbot slaves)
I'm not sure exactly what the purpose or mechanism for /external is. Sure,
it's like a snapshot dir, probably used for to
On Sun, Apr 5, 2009 at 6:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
Alexandre Vassalotti alexandre at peadrop.com writes:
Off the top of my head, the following is needed for a successful migration:
There's also the issue of how we adapt the current workflow of svnmerging
between
(going back on-list)
On 05/04/2009 15:42, Alexandre Vassalotti wrote:
I'm pretty sure that we'll need to reconvert; I don't think the current
conversion is particularly good.
What is bad about it?
For one thing, it has the [svn] prefixes, which I found to be quite
ugly. hgsubversion in
On 05/04/2009 15:11, Alexandre Vassalotti wrote:
I am not sure if it would be useful to convert the old branches to
Mercurial. The simplest thing to do would be to keep the current svn
repository as a read-only archive. And if people needs to commit to
these branches, they could request the
Hello,
hgsubversion in many cases will preserve the rev order from svn so
that the local revision numbers that hg shows will be the same as in SVN
anyway.
Er... I guess it's only the case in simplistic cases where you convert all
branches in the SVN repo to a single hg repo (which is not
On 05/04/2009 16:39, Antoine Pitrou wrote:
The other nice thing with having [svn rXXX] in the patch subject line is that
it makes the info easily viewable and searchable in the Web front-end.
We can still make it accessible/searchable on the web if we don't put it
in the commit message.
I
Dirkjan Ochtman dirkjan at ochtman.nl writes:
I also think 100MB+ is a cheap price to pay,
given you only pay it in disk space (cheap) and initial clone time (not
very often, and usually still quite fast).
It is a cheap price to pay if there is a significant return for it. In my
experience
On 05/04/2009 17:18, Antoine Pitrou wrote:
It is a cheap price to pay if there is a significant return for it. In my
experience using the hg mirror of the py3k branch, I don't remember having had
to run annotate on the trunk to hunt for a change that I'd witnessed in py3k.
Other developers may
2009/4/5 Antoine Pitrou solip...@pitrou.net:
Dirkjan Ochtman dirkjan at ochtman.nl writes:
I also think 100MB+ is a cheap price to pay,
given you only pay it in disk space (cheap) and initial clone time (not
very often, and usually still quite fast).
It is a cheap price to pay if there is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 5, 2009, at 5:06 AM, Martin v. Löwis wrote:
- decide what to do with the bzr mirrors
I don't see any reason to keep them running on python.org. There are,
or will be, other alternatives.
Barry
-BEGIN PGP SIGNATURE-
Version:
I am not sure if it would be useful to convert the old branches to
Mercurial. The simplest thing to do would be to keep the current svn
repository as a read-only archive. And if people needs to commit to
these branches, they could request the branch to be imported into a
Mercurial branch (or
I'm not sure exactly what the purpose or mechanism for /external is. Sure,
it's like a snapshot dir, probably used for to pull some stuff into other
process? Seems to me like it might be interesting to, for example, convert
to a simple config file + script that lets you specify a package
Sounds sane. Would I be able to get access to PSF infrastructure to get
started on that, or do you want me to get started on my own box? I'll
probably do the conversion on my own box, but for authn/authz it might
be useful to be able to use PSF infra.
Now that Alexandre has also volunteered,
Dirkjan Ochtman wrote:
On 05/04/2009 11:06, Martin v. Löwis wrote:
In particular, the Stackless people have requested that they move along
with what core Python does, so their code should also be converted.
I'd be interested to hear if they want all of their stuff converted, or
just the
We should probably not include any branches that haven't been touched in
the last 18 months. Then we also leave out branches that have been pruned.
BTW, tags are also missing from the current conversions. We probably
want to keep all release tags, but not the partial tags (e.g. the
On 05/04/2009 19:50, Martin v. Löwis wrote:
Ok, that's a problem. We currently run 0.7.5 on the master, and have
made custom changes that need to be forward-ported. IIUC, this will
also mean that the waterfall default page is gone, which might surprise
people.
I suppose all slaves also need to
On 05/04/2009 19:37, Martin v. Löwis wrote:
Any decision to have or not have such a feature should be stated in
the PEP. I personally don't use IDEs, so I don't care (although
I do notice that the apparent absence of IDE support for Mercurial
indicates maturity of the technology)
Well, there
401 - 500 of 538 matches
Mail list logo
