"Martin v. Löwis" wrote:
> 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
>> sta
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 initi
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 passw
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
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 neede
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
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
__
shutil.co
Guido van Rossum wrote:
> I hope we're correctly estimating the effort required to manage the
> server and the users. 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
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
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 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
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 U
[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 che
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
[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
probl
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
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, w
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 t
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
> > Sample results of this conversion are available at
> >
[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 p
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
>al
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:
> 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
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.
>
> 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
http://mail.python.org/mailman/listin
[...]
> 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 web
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
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 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
Aahz wrote:
> On Sun, Jul 24, 2005, Chuck Robey wrote:
>
>>I'm trying to get Python installed on a Zaurus, running OpenBSD.
>
>
> While python-dev can be a good place to get questions like this
> answered, many more people read comp.lang.python, and you should ask
> there, too.
Thanks ... I f
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 trick
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 Py
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 per
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 p
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 v
35 matches
Mail list logo
