On 18/08/2009 6:20 PM, Dirkjan Ochtman wrote:
On Tue, Aug 18, 2009 at 10:12, Martin v. Löwismar...@v.loewis.de wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
I think the most important item
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written, with a name that does not
have win32 as a
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownership of anything. It's always individuals who
On 23/08/2009 5:25 PM, Martin v. Löwis wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken
Mark Hammond wrote:
On 23/08/2009 5:25 PM, Martin v. Löwis wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has
On Sat, Aug 22, 2009 at 01:17, Martin Geislerm...@lazybytes.net wrote:
In the general case, you can specify an extension to be enabled by
filename:
[extensions]
foo = ~/src/foo
So if I can enable an extension like that on your system, I might be
evil and commit a bad extension *and*
Stephen J. Turnbull step...@xemacs.org writes:
Mark Hammond writes:
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's ini file semantics if currently it
refuses to parse [extension] sections in versioned hgrcs.
It doesn' refuse anything like
Stephen J. Turnbull step...@xemacs.org writes:
Mark Hammond writes:
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Possibly - although I would expect the existing section names be reused
when applied to a versioned file, I'd be more than happy for the hg guys
to declare new
2009/8/22 Martin Geisler m...@lazybytes.net:
Oh, we try to be very paranoid in Mercurial :-) That's why you don't see
any support for copying hgrc files when you clone and why hg wont trust
hgrc files not owned by you: it should be safe to do
cd ~collegue/src/python
hg tip
So, is the
Paul Moore p.f.mo...@gmail.com writes:
2009/8/22 Martin Geisler m...@lazybytes.net:
Oh, we try to be very paranoid in Mercurial :-) That's why you don't
see any support for copying hgrc files when you clone and why hg wont
trust hgrc files not owned by you: it should be safe to do
cd
Stephen J. Turnbull wrote:
Dirkjan Ochtman writes:
[Clients] cannot be trusted (e.g. I might put a win32text stub in
there somewhere that does nothing).
Heck, just edit the .hgrules file, and do a Houdini on any and all
handcuffs.
Don't trust software, trust people -- but help them
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Possibly - although I would expect the existing section names be reused
when applied to a versioned file, I'd be more than happy for the hg guys
to declare
On 22/08/2009 7:09 PM, Martin v. Löwis wrote:
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written,
[Adjusted the CCs...]
On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
On Tue, Aug 18, 2009 at 2:12 AM, Martin v. Löwismar...@v.loewis.de wrote:
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered, but it
On Fri, Aug 21, 2009 at 09:16, Mark Hammondskippy.hamm...@gmail.com wrote:
I'm resurrecting my patch to support a filter called 'none' (which is
turning out to be harder than I thought). Off the top of my head, it would
the following would give us a pretty solid solution:
* Finish my patch
Mark Hammond writes:
* Add support for versioned 'filter rules' - eg, /.hgfilters or similar.
* This might be pushing my luck, but: add 'defensive' support to core hg
for this feature - if /.hgfilters exists, hg should refuse to operate on
the working tree unless the win32text
Stephen J. Turnbull wrote:
Note that Bazaar is currently discussing some similar policies. I
think the name they have settled on is .bzrrules. Maybe .hgrules is
a better name.
So it would be .hgrules/extensionname? With the extension then
defining the contents of the rule file?
An
Nick Coghlan writes:
Stephen J. Turnbull wrote:
Note that Bazaar is currently discussing some similar policies. I
think the name they have settled on is .bzrrules. Maybe .hgrules is
a better name.
So it would be .hgrules/extensionname? With the extension then
defining the
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammondskippy.hamm...@gmail.com wrote:
Maybe you can enumerate what you think needs to change in mercurial, then
once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to be passed the filename they are
working on so
On Fri, Aug 21, 2009 at 16:10, Dj Gilcreasedigitalx...@gmail.com wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you just have a hgrc file
that works the same as the
On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote:
Enabling extensions in a versioned file is not going to fly.
any specific reason?
___
Python-Dev mailing list
Python-Dev@python.org
Dj Gilcrease digitalx...@gmail.com writes:
On Fri, Aug 21, 2009 at 8:19 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote:
Enabling extensions in a versioned file is not going to fly.
any specific reason?
In the general case, you can specify an extension to be enabled by
filename:
[extensions]
On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcreasedigitalx...@gmail.com wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you
On 22/08/2009 12:10 AM, Dj Gilcrease wrote:
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammondskippy.hamm...@gmail.com wrote:
Maybe you can enumerate what you think needs to change in mercurial, then
once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to
Mark Hammond writes:
Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
[config] # or maybe [rules] ?
required_extensions = win32text, some_pydev_specific_extension
[extensions]
required_for_commit = win32text,some_other_ext
That might require a change to hg's ini
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
[config] # or maybe [rules] ?
required_extensions = win32text, some_pydev_specific_extension
[extensions]
This is a repost from two weeks ago. It didn't get much feedback last
time. I still keep trying, reposting to python-list also this time.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
On Tue, Aug 18, 2009 at 10:12, Martin v. Löwismar...@v.loewis.de wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
I think the most important item here is currently the win32text stuff.
Mark
On 18/08/2009 6:20 PM, Dirkjan Ochtman wrote:
On Tue, Aug 18, 2009 at 10:12, Martin v. Löwismar...@v.loewis.de wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
I think the most important item
On Tue, Aug 18, 2009 at 13:32, Mark Hammondmhamm...@skippinet.com.au wrote:
I can make time, somewhat spasmodically, starting fairly soon. Might I
suggest that as a first task I can resurrect my old stale patch, and you can
arrange to install win32text locally and start experimenting with how
[stripping out python-list and Mark from the CC]
On Tue, Aug 18, 2009 at 01:20, Dirkjan Ochtmandirk...@ochtman.nl wrote:
On Tue, Aug 18, 2009 at 10:12, Martin v. Löwismar...@v.loewis.de wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that
On Tue, Aug 18, 2009 at 21:46, Brett Cannonbr...@python.org wrote:
Can we possibly get these todo items in the PEP? I keep looking at the
PEP out of habit to see what the blockers are and they are not there,
at which point I have to dig up Martin's email.
Will do.
Cheers,
Dirkjan
On Tue, Aug 18, 2009 at 2:12 AM, Martin v. Löwismar...@v.loewis.de wrote:
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered, but it seems some volunteer needs to be in charge,
keeping track of a
This is a repost from a month ago. It didn't get much feedback last
time. I have now two items.
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
Item 1
--
The first item is build identification. If
Sorry Dirkjan - I just noticed I didn't CC you on this mail originally.
I'm wondering if you have any more thoughts on these EOL issues and if
there is anything I can do to help?
Cheers,
Mark
On 4/07/2009 2:03 PM, Mark Hammond wrote:
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
...
I think
2009/7/4 Brett Cannon br...@python.org:
While I really like the idea of using named branches for each release so
that there is a single py3k branch that contains all relevant history
for
every release, I think we should start simple and go with cloned
branches.
That way the workflow
Hagen Fürstenau wrote:
be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
I think the tag is correct. Note that the concept of tagging is
different in Mercurial, where a tag can only refer to a revision
previous to
According to
http://hg.python.org/cpython/tags?revcount=50
the tag r301 belongs to revision be32850b093f. However, this
is really r69557, which was not tagged. be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
Regards,
be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
I think the tag is correct. Note that the concept of tagging is
different in Mercurial, where a tag can only refer to a revision
previous to the one where it is
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburgm...@egenix.com wrote:
Is there a standard notation for hg revisions that roundup could
detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
(Sorry for my absence from the discussion for some time. I'll try to
update
Brett Cannon wrote:
On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg m...@egenix.com wrote:
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.
Dirkjan Ochtman wrote:
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburgm...@egenix.com wrote:
Is there a standard notation for hg revisions that roundup could
detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
Hmm, no prefix or suffix ?
So we'll always have
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburgm...@egenix.com wrote:
Hmm, no prefix or suffix ?
No, not really. hg often shows revision integers as well, but as they
aren't globally consistent, they're of little value in communicating
changeset pointers.
So we'll always have to write see
On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
The merge process itself is more or less clear. What I'm missing
is the agreed upon strategy for applying the patches to the various
branches.
I've seen a few discussions about this, but no final statement
of what strategy to follow and whether
M.-A. Lemburg wrote:
Dirkjan Ochtman wrote:
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburgm...@egenix.com wrote:
Is there a standard notation for hg revisions that roundup could
detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
Hmm, no prefix or suffix ?
Hmm, no prefix or suffix ?
No, not really. hg often shows revision integers as well, but as they
aren't globally consistent, they're of little value in communicating
changeset pointers.
I think MAL wasn't asking for a 1354: prefix, but for a, say,
r or R prefix, or perhaps V or merc:.
I
I've seen a few discussions about this, but no final statement
of what strategy to follow and whether hg makes this easier (AFAIR,
that was the main argument for switching to hg).
I think the main reason for switching was that it would make it easier
for non-core-committers to maintain
Martin v. Löwis wrote:
I think you are proposing that there is no prefix because the chance
for a misidentification of some word as a hg revision number is small,
as it has to be exactly 12 hex digits.
So triggering it accidentally would require a 12 letter word or object
name that used only
R. David Murray writes:
On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
I've seen a few discussions about this, but no final statement
of what strategy to follow and whether hg makes this easier (AFAIR,
that was the main argument for switching to hg).
Yes, yes, yes, and no. In
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.
Two things:
* We need some form of documentation of how committers are expected
to
On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg m...@egenix.com wrote:
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.
Two things:
*
M.-A. Lemburg wrote:
Dirkjan Ochtman wrote:
* Our tracker, checkin messages, online documentation and lots of
Python resources on the web are full of references to the
Subversion rXYZ notation of changesets.
The PEP has to provide some way to gracefully provide a redirect
from
I suggest that we also run a version of that redirection filter to remap
the old svn.python.org links in addition to making them accessible
through hg.python.org as Dirkjan proposed.
Not sure what links you are talking about, but we also need to keep the
current svn.python.org up as-is, for
Martin v. Löwis wrote:
I suggest that we also run a version of that redirection filter to remap
the old svn.python.org links in addition to making them accessible
through hg.python.org as Dirkjan proposed.
Not sure what links you are talking about, but we also need to keep the
current
Martin v. Löwis schrieb:
We could add another value in the tuple that specifies the VCS:
('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that
VCSs are not universally the same, but the concept of a revision is
universal.
Actually, I think that's not the case. For bzr, the
Martin v. Löwis schrieb:
It will handle it, for sure, but I think it would all go easier if we
could work with stricter subset branches (and leave the effective
cherrypicking for the occasional problem).
So I think the PEP should propose a workflow (or: merge flow) if you
think we would be
Georg Brandl writes:
What I really want to see is the common-subset approach for
maintenance branches.
IMO, this unfortunately unlikely to work as you seem to expect, for a
two technical reasons and for a social reason. The first technical
reason is that a maintenance branch really is a
In proposing such a workflow, consider these requirements:
It seems that there is a consensus to separate the 2.x and 3.x repos,
and that also makes sense to me.
(I think) I wasn't primarily talking about the representation of
branches in hg - to that, I fully trust recommendations from hg
Is it really that confusing? I have never heard of anyone asking what
is py3k?
Do you read python-list? It has been asked. Also, some people seem to
think that py3k is different from python 3.
Personally, I vote for keeping the 3k for 3000 (or is it 3072?). I
believe that py3k represents a
2009/7/5 average dreamingforw...@gmail.com:
Is it really that confusing? I have never heard of anyone asking what
is py3k?
Do you read python-list? It has been asked. Also, some people seem to
think that py3k is different from python 3.
Personally, I vote for keeping the 3k for 3000 (or is
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
So far, I have only one item: build identification. If you want to work
on this, please either provide a patch (for trunk and/or py3k), or
(if you are a
Hi Martin,
Martin v. Löwis wrote:
In this thread, I'd like to collect things that ought to be done
but where Dirkjan has indicated that he would prefer if somebody else
did it.
So far, I have only one item: build identification. If you want to work
on this, please either provide a patch
Martin v. Löwis wrote:
What will need debate and discussion in the PEP is the workflow, ie.
the order in which changes should be applied to the branches.
Particularly since there isn't even one true workflow *now*. I see
three main variants go by on Python-checkins:
- svnmerge based
- commit
I do want to help, but I believe I'll only have time a week from now.
If we need/want Roundup tweaks to go with Mercurial, I can work on
that (keep in mind we have a cool GSoC student working on
Mercurial-Roundup integration, and I'm willing to work on our needs
with him).
I think that's
On Fri, Jul 3, 2009 at 20:04, Brett Cannonbr...@python.org wrote:
Fine by me as long as people realize that if anything is questionable then
the switch will not happen. Getting this right takes precedence over any
deadline. And obviously we will need to do at least one live conversion on
On Sat, Jul 4, 2009 at 07:13, Nick Coghlanncogh...@gmail.com wrote:
I'd guess that the only way to keep those functional is to keep
svn.python.org around in read-only mode.
No, actually: the idea (I think I floated it in the PEP, as well), is
that I can write a simple extension for hgweb that
On Fri, Jul 3, 2009 at 17:17, Georg Brandlg.bra...@gmx.net wrote:
Do you have a key to the second column in that file? E.g. the difference
between strip and discard is not clear to me. strip partial?
strip == discard. strip = remove, merged should be obvious, keep-clone
means we'll keep the
On Sat, Jul 4, 2009 at 00:09, Martin v. Löwismar...@v.loewis.de 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.
Yeah, I mean just the linking here.
In the
On Sat, Jul 4, 2009 at 00:37, Barry Warsawba...@python.org wrote:
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
Brett Cannon 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.
Is it really that confusing? I have never heard of anyone asking what
is py3k?
Do
I see that George Brandl and Martin van Loewis seem to be accomodating
your viewpoint, but I don't get the impression that either you (as the
hg migration proponent) nor they (as core committers) realize how far
apart your assumptions are.
Actually, I (probably) don't agree to a merge flow
Dirkjan Ochtman wrote:
On Sat, Jul 4, 2009 at 07:13, Nick Coghlanncogh...@gmail.com wrote:
I'd guess that the only way to keep those functional is to keep
svn.python.org around in read-only mode.
No, actually: the idea (I think I floated it in the PEP, as well), is
that I can write a simple
On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Fri, Jul 3, 2009 at 20:04, Brett Cannonbr...@python.org wrote:
Fine by me as long as people realize that if anything is questionable
then
the switch will not happen. Getting this right takes precedence over any
On Sat, Jul 4, 2009 at 01:55, Terry Reedy tjre...@udel.edu wrote:
Brett Cannon 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.
Is it really that
On Sat, 4 Jul 2009 at 12:28, Brett Cannon wrote:
On Sat, Jul 4, 2009 at 01:03, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Fri, Jul 3, 2009 at 20:04, Brett Cannonbr...@python.org wrote:
Fine by me as long as people realize that if anything is questionable
then
the switch will not happen.
On Fri, Jul 3, 2009 at 01:01, Mark Hammondskippy.hamm...@gmail.com wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and it isn't clear to me how that would work with
Dirkjan Ochtman writes:
Mercurial has two basic ways of using branches: cloned branches, where
each branch is kept in a separate repository, and named branches,
where each revision keeps metadata to note on which branch it belongs.
The former makes it easier to distinguish branches, at
On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 01:01, Mark Hammondskippy.hamm...@gmail.com wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and
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 tools are good enough to preserve existing EOL
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 you say below.
Ditto named
Mark Hammond 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 tools are good enough to preserve
existing EOL styles, I've found myself accidentally checking in
Dirkjan Ochtman schrieb:
- Fifth, here's a list of things, off the top of my head, that still need
doing:
* Get agreement on branch strategy and branch processing (list of
branches + proposed handling at
http://hg.python.org/pymigr/file/tip/all-branches.txt) --- PLEASE
REVIEW
Do you
On Thu, Jul 2, 2009 at 13:42, Dirkjan Ochtman dirk...@ochtman.nl 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.
- First of all, I've got the basic
Dirkjan Ochtman wrote:
It needs to be decided where the hg repositories will live. I'd like
to propose to keep the hgwebdir instance at hg.python.org. This is an
accepted standard for many organizations, and an easy parallel to
svn.python.org. The 2.7 (trunk) repo might live at
Terry Reedy wrote:
Dirkjan Ochtman wrote:
It needs to be decided where the hg repositories will live. I'd like
to propose to keep the hgwebdir instance at hg.python.org. This is an
accepted standard for many organizations, and an easy parallel to
svn.python.org. The 2.7 (trunk) repo might live
On Fri, Jul 03, 2009, Brett Cannon wrote:
Should we consider adding a sys.revision attribute and begin the deprecation
of sys.subversion?
+1
--
Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/
as long as we like the same operating system, things are cool. --piranha
So we must work without effective EOL support?
If that's the case (i.e. no effective EOL support, the way svn
supported it), then I think the PEP should make that clear (e.g.
in a discussion section).
For the server-side hooks: it would be good to know exactly
what they check, wrt. line
It will handle it, for sure, but I think it would all go easier if we
could work with stricter subset branches (and leave the effective
cherrypicking for the occasional problem).
So I think the PEP should propose a workflow (or: merge flow) if you
think we would be better off with a different
Should we consider adding a sys.revision attribute and begin the
deprecation of sys.subversion?
I wouldn't mind killing sys.subversion right away (i.e. in trunk
and 3k - obviously it has to stay in 2.6 and 3.1, and all the older
branches).
I'm -1 on calling it sys.revision, as this makes it
MRAB wrote:
Terry Reedy wrote:
Dirkjan Ochtman wrote:
It needs to be decided where the hg repositories will live. I'd like
to propose to keep the hgwebdir instance at hg.python.org. This is an
accepted standard for many organizations, and an easy parallel to
svn.python.org. The 2.7 (trunk)
This is exactly why I was asking for your advice - I can't work out how to
work effectively with win32text as it stands myself, so remain stuck
accidently checking in files with inappropriate line endings and stuck
working out how to move pywin32's CVS repo with abandoning the very
primitive
On Fri, Jul 3, 2009 at 14:00, Martin v. Löwis mar...@v.loewis.de wrote:
Should we consider adding a sys.revision attribute and begin the
deprecation of sys.subversion?
I wouldn't mind killing sys.subversion right away (i.e. in trunk
and 3k - obviously it has to stay in 2.6 and 3.1, and all
On Fri, Jul 3, 2009 at 11:22, Terry Reedy tjre...@udel.edu wrote:
Dirkjan Ochtman wrote:
It needs to be decided where the hg repositories will live. I'd like
to propose to keep the hgwebdir instance at hg.python.org. This is an
accepted standard for many organizations, and an easy parallel
We could add another value in the tuple that specifies the VCS:
('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that
VCSs are not universally the same, but the concept of a revision is
universal.
Actually, I think that's not the case. For bzr, the usual way of
identifying a
On Fri, Jul 3, 2009 at 14:52, Martin v. Löwis mar...@v.loewis.de wrote:
We could add another value in the tuple that specifies the VCS:
('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that
VCSs are not universally the same, but the concept of a revision is
universal.
So are you saying we should drop the idea of a revision value
altogether, or just embrace the differences and add a sys.mercurial
attribute?
That's what I would propose. It should be a best-effort(*) approach at
providing all information that is needed to really find the source
used for the
On Fri, Jul 3, 2009 at 23:41, Brett Cannonbr...@python.org wrote:
If we make it universal I say it should be '2.x' and '3.x'. The whole 'py'
prefix is redundant.
Right, I was aiming for /python/2.x and /python/3.x as well.
Actually, I currently have /cpython to also make CPython less special
On Fri, Jul 3, 2009 at 15:00, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Fri, Jul 3, 2009 at 23:41, Brett Cannonbr...@python.org wrote:
If we make it universal I say it should be '2.x' and '3.x'. The whole
'py'
prefix is redundant.
Right, I was aiming for /python/2.x and /python/3.x as
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 have a sys.subversion[2]
- First of all, I've got the basic conversion down, I've done it a few
times now, with progressively better results. You can view some
results at http://hg.python.org/, which has a preliminary cpython
repository. *** The changeset hashes for that repo will change, so you
won't be able to
301 - 400 of 538 matches
Mail list logo
