On 7/27/05, Steven Bethard [EMAIL PROTECTED] wrote:
Here's the draft for the first half of July.
Thanks! This is looking great! (Although I can't help you with the
GCC/C++ thread -- I've been avoiding that one like the plague myself.
:-)
To all the contributors, great job guys!
--
--Guido van
I'd like to see the Python source be stored in Subversion instead
of CVS, and on python.org instead of sf.net. To facilitate discussion,
I have drafted a PEP describing the rationale for doing so, and
the technical procedure to be performed.
This is for discussion on python-dev and eventual BDFL
On 7/28/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
I'd like to see the Python source be stored in Subversion instead
of CVS, and on python.org instead of sf.net. To facilitate discussion,
I have drafted a PEP describing the rationale for doing so, and
the technical procedure to be performed.
On Thu, Jul 28, 2005 at 10:00:00PM +0200, Martin v. L?wis wrote:
I'd like to see the Python source be stored in Subversion instead
of CVS, and on python.org instead of sf.net.
+1, +1.
CVS has a number of limitations that have been elimintation by
Subversion. For the development of Python,
On Jul 28, 2005, at 4:20 PM, Guido van Rossum wrote:
Managing users is especially important -- if a
user is compromised (as has happened in the past for python.org users)
the whole repository is compromised. Now this could happen to SF users
too, but I'm not sure that we know all the tricks
On Thu, 2005-07-28 at 16:00, Martin v. Löwis wrote:
I'd like to see the Python source be stored in Subversion instead
of CVS
+1
, and on python.org instead of sf.net.
+0
I know that SF has promised svn access to projects for a long time now,
but I haven't heard anything from them in a long
On Thu, 2005-07-28 at 16:20, Guido van Rossum wrote:
I hope we're correctly estimating the effort required to manage the
server and the users.
Yah, me too! ;)
We are building some experience with this though, having moved many of
the system files, and all of the web pages, to svn. So far,
On Thu, 2005-07-28 at 17:58, James Y Knight wrote:
If you use the fsfs storage mechanism for subversion, it is somewhat
simpler to verify that the repository is not compromised. Each commit
is represented as a separate file, and thus old commits are never
modified. Only new files are
[...]
Publish the Repositories
[...]
As an option, websvn (available
e.g. from the Debian websvn package) could be provided.
Is there any reason that this should be an option, and not just done? For
occasional source (particularly C source) lookups, I've found webcvs
Do we also want to split off nondist and encodings? IWBNI
the Python source code proper weren't buried too deep in the
directory structure.
+1
=Tony.Meyer
___
Python-Dev mailing list
Python-Dev@python.org
On 7/28/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Thu, 2005-07-28 at 16:00, Martin v. Löwis wrote:
I'd like to see the Python source be stored in Subversion instead
of CVS
+1
+1 from me as well; single commit numbers for commits across multiple
files will be wonderful.
, and on
Martin v. Löwis wrote:
Converting the CVS Repository
=
The Python CVS repository contains two modules: distutils and
python. Keeping them together will produce quite long repository
URLs, so it is more convenient if the Python CVS and the distutils
CVS are
I theory Subversion should allow you to be more secure. CVS has a very
limited concept of security and for the most part you need to rely on SSH.
Subversion makes use of Apache as one of its server options. Any
authentication method you can use in Apache 2 you can use for Subversion.
Once Apache
Martin v. Löwis wrote:
Currently, access to Subversion on svn.python.org uses WebDAV over
https, using basic authentication. For this to work, authorized
users need to provide a password. This mechanism should be used,
atleast initially, for the Python CVS as well, since various committers
also
[Martin v. Löwis]
I'd like to see the Python source be stored in Subversion instead
of CVS, and on python.org instead of sf.net. To facilitate discussion,
I have drafted a PEP describing the rationale for doing so, and
the technical procedure to be performed.
This is for discussion on
On Thursday 28 July 2005 07:21 pm, Tim Peters wrote:
[Martin v. Löwis]
The conversion should be done using cvs2svn utility, available e.g.
in the cvs2svn Debian package. The command for converting the Python
repository is
snip
Sample results of this conversion are available at
On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:
I'm definitely positive to a migration to Subversion, but I'd be really
concerned about using plain text authentication mechanisms.
We won't use plain text, but we may (or, we currently do) use basic auth
over ssl. The security then is in
On Jul 28, 2005, at 3:19 PM, Barry Warsaw wrote:
On Thu, 2005-07-28 at 20:15, Leif Hedstrom wrote:
I'm definitely positive to a migration to Subversion, but I'd be
really
concerned about using plain text authentication mechanisms.
We won't use plain text, but we may (or, we currently
Tim Peters wrote:
[Martin v. Löwis]
The conversion should be done using cvs2svn utility, available e.g.
in the cvs2svn Debian package. The command for converting the Python
repository is
[...]
I'm sending this to Jim Fulton because he did the conversion of Zope
Corp's code base to SVN.
[Jeff Rush]
The conversion script isn't perfect and does fail on complex CVS
arrangements or where there is extensive history to migate. However it
appears above that Martin has already tried the script out, with success.
I'd still like to hear from Jim, as I don't believe all serious
On Thu, 2005-07-28 at 22:14, Tim Peters wrote:
Ah, before I forget, single repository has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):
http://svn.zope.org/
Long URLs don't really get in the way in practice (rarely a need to
[Tim]
Ah, before I forget, single repository has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):
http://svn.zope.org/
Long URLs don't really get in the way in practice (rarely a need to
type one after initial checkout; even svn
On Thu, Jul 28, 2005, Barry Warsaw wrote:
On Thu, 2005-07-28 at 22:14, Tim Peters wrote:
Ah, before I forget, single repository has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):
http://svn.zope.org/
Long URLs don't really
On Thu, 2005-07-28 at 22:59, Tim Peters wrote:
Yup, me too -- between the two of us, we don't have enough fingers to
count how many trunks, branches, and tags of ZODB and Zope I have to
fiddle with.
I have a small inkling of your pain.
They're all still copy, paste, tail-edit for me, and--
Barry Warsaw wrote:
I know that SF has promised svn access to projects for a long time now,
but I haven't heard anything from them in a long time. It's listed
under their Strategic Projects but the last update to that news item
was back in April. Question: do we wait for SF to make the
On Thursday 28 July 2005 20:07, Fernando Perez wrote:
or something similar. It's an extra few chars, and it would give a
convenient way to branch off pieces of the main code into their own
subprojects in the future if needed.
More interestingly, keeping it in a single repository makes it
Patch / Bug Summary
___
Patches : 357 open ( +7) / 2885 closed ( +3) / 3242 total (+10)
Bugs: 898 open ( +9) / 5144 closed ( +3) / 6042 total (+12)
RFE : 191 open ( +2) / 178 closed ( +0) / 369 total ( +2)
New / Reopened Patches
__
Tony Meyer wrote:
Is there any reason that this should be an option, and not just done?
Certainly: it's administrator load, which in turn is volunteer time.
For
occasional source (particularly C source) lookups, I've found webcvs really
useful (especially when on a machine without cvs or
On 7/29/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Thursday 28 July 2005 20:07, Fernando Perez wrote:
or something similar. It's an extra few chars, and it would give a
convenient way to branch off pieces of the main code into their own
subprojects in the future if needed.
Fred L. Drake, Jr. wrote:
More interestingly, keeping it in a single repository makes it easier to
merge
projects, or parts of projects, together, without losing the history. This
would be useful when developing packages that may be considered for the
standard library, but which also
Barry Warsaw wrote:
We won't use plain text, but we may (or, we currently do) use basic auth
over ssl. The security then is in the passwords, so we have to make
sure they're generated securely.
That (sort of) *is* plain text passwords. Somebody who took over
svn.python.org can get the
Tim Peters wrote:
Ah, before I forget, single repository has worked very well for Zope
(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
projects):
http://svn.zope.org/
Long URLs don't really get in the way in practice (rarely a need to
type one after initial
32 matches
Mail list logo
