"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> - Subversion over SSH, using SSH key pairs. This would require
> to give committers accounts on the machine, which currently is
> ruled out by the administration policy of svn.python.org.
Would it work/how much risk would it be to create account
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. To facilitate discussion,
> I have drafted a PEP describing the rationale for doing so, and
> the technical procedure to be performed.
Not sure about th
Tim Peters wrote:
...
> I'm sending this to Jim Fulton because he did the conversion of Zope
> Corp's code base to SVN. Unfortunately, Jim will soon be out of touch
> for several weeks. Jim, do you have time to summarize the high bits
> of the problems you hit? IIRC, you didn't find any conversi
Tim Peters wrote:
> [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 d
Martin v. Löwis wrote:
> 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 ne
On Friday 29 July 2005 06:34, M.-A. Lemburg wrote:
> If SF is such a show-stopper, would it be reasonable to
> look for managed alternatives, such as eg. CollabNet (who
> funded Subversion development) ?
docutils has been using berlios.de for Subversion; that might be a reasonable
option. I'm
Martin v. Löwis wrote:
> So do you use project/trunk or trunk/project? If the former, I would
> need to get instructions on how to do the conversion from CVS.
project/trunk/
On Friday 29 July 2005 02:12, Fernando Perez wrote:
> For ipython, which recently went through cvs2svn, I found that mov
Why does math have an fabs function? Both it and the abs builtin function
wind up calling fabs() for floats. abs() is faster to boot.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Friday 29 July 2005 09:17, Jim Fulton wrote:
> 1. We were making extensive use of symbolic links to share packages
> among various Zope projects. This requires special care and
> was the main reason I wrote my own scrips.
>
> I don't expect that this would be an issue for Pytho
[Skip]
> Why does math have an fabs function? Both it and the abs builtin function
> wind up calling fabs() for floats. abs() is faster to boot.
Nothing deep -- the math module supplies everything in C89's standard
libm (+ a few extensions), fabs() is a std C89 libm function.
There isn't a clea
M.-A. Lemburg wrote:
>>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.
>
>
> Not sure about the move to svn.python.org. This would
> bind additional developer resources for
Jim Fulton wrote:
>I don't expect that this would be an issue for Python.
Right.
> 2. I initially tried to conver our entire repository, including all
>branches. This would have taken days. I finally decided to just
>convert our trunk, which took several hours. The main time
>s
Jim Fulton wrote:
> I did convert projects individually. I told cvs2svn to just create dump
> files. I then used svnload to load the dump files myself so that
> I could make each project a top-level directory with it's own
> trunk, branches and tags.
>
> I'd be happy to share my scrips, although
Martin v. Löwis wrote:
> Jim Fulton wrote:
>
>> I don't expect that this would be an issue for Python.
>
>
> Right.
>
>
>>2. I initially tried to conver our entire repository, including all
>> branches. This would have taken days. I finally decided to just
>> convert our trunk, which t
Martin v. Löwis wrote:
> Jim Fulton wrote:
>
>>I did convert projects individually. I told cvs2svn to just create dump
>>files. I then used svnload to load the dump files myself so that
>>I could make each project a top-level directory with it's own
>>trunk, branches and tags.
>>
>>I'd be happy
Fernando Perez wrote:
> For ipython, which recently went through cvs2svn, I found that moving over to
> a
> project/trunk structure was a few minutes worth of work. Since svn has moving
> commands, it was just a matter of making the extra project/ directory and
> moving things one level down the
Michael Hudson wrote:
> Would it work/how much risk would it be to create accounts with shell
> /bin/false?
It seems that the pydotorg admins are worried about such a prospect.
I believe this alone either won't work or won't be good enough (not
sure which one): If you have /bin/false as login she
Jim Fulton wrote:
>> Dunno. For the Python CVS (which translates into some 40,000 revisions),
>> on the machine which I was originally using (1GHz Pentium), conversion
>> took 7h. On my current workstation, it takes a little over an hour.
>
>
> Was this with the file-system back end? What is you
On Fri, 2005-07-29 at 01:00, "Martin v. Löwis" wrote:
> 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
On Fri, 2005-07-29 at 00:44, "Martin v. Löwis" wrote:
> - assignment of passwords. This I don't like about the current
> pydotorg setup - there should be a way to chose your own password;
> perhaps without involving an administrator.
> I could imagine a web form for password change, and admi
"Martin v. Löwis" wrote:
> Fernando Perez wrote:
>> For ipython, which recently went through cvs2svn, I found that moving over
>> to a
>> project/trunk structure was a few minutes worth of work. Since svn has
>> moving commands, it was just a matter of making the extra project/ directory
>> and
>
Barry Warsaw wrote:
>
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.
>
>
I'll play around with it some this weekend, see what's
On Fri, 2005-07-29 at 17:19, "Martin v. Löwis" wrote:
> I believe this alone either won't work or won't be good enough (not
> sure which one): If you have /bin/false as login shell, and still
> manage to invoke /usr/bin/svnserve remotely, you can likely also
> invoke /usr/bin/cat /etc/passwd remot
On Fri, 2005-07-29 at 00:35, "Martin v. Löwis" wrote:
> It's also a convenience issue, and has social aspects. For example,
> firstname.lastname does not work quite well for me, either
> (martin.v.loewis or martin.von.loewis would work better; likewise
> guido.van.rossum?), other users prefer not
Barry Warsaw wrote:
> I disagree. By reserving password generation to the pydotorg admins, we
> can better insure the passwords are more robust against dictionary
> attacks. See my previous message. I actually /don't/ want individuals
> to be able to set their own passwords. In practice, you on
On Fri, 2005-07-29 at 17:32, "Martin v. Löwis" wrote:
> > Was this with the file-system back end? What is your current system?
>
> Yes, and it is a 3 GHz dual processor (although I don't think it uses
> two processors) with 1GB RAM (I believe RAM size matters a lot for
> this process; the older
Barry Warsaw wrote:
>>That (sort of) *is* plain text passwords. Somebody who took over
>>svn.python.org can get the password. In public-key or digest
>>authentication, this won't be possible.
>
>
> Actually, the passwords are still hashed in the file, so they wouldn't
> be able to extract the pla
On Fri, 2005-07-29 at 00:50, Christopher Petrilli wrote:
> Another thing to look at would be Trac, which we are in the process of
> moving to from the horrendous nightmare of Bugzilla. It's integration
> with SVN as well as Wiki is quite amazing.
Now's the time I pipe in to remind everyone that
At 05:54 PM 7/29/2005 -0400, Barry Warsaw wrote:
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.
From the svnserve man page:
-t,
On Fri, 2005-07-29 at 17:21, "Martin v. Löwis" wrote:
> Doesn't this give issues as *every* file the starts out renamed? e.g.
> what if you want "revision 100 of project/trunk/foo", but, at revision
> 100, it really was trunk/project/foo?
I think it only matters if you use urls. I working direct
On Fri, 2005-07-29 at 16:59, "Martin v. Löwis" wrote:
> Perhaps. Somebody would need to research the precise migration
> procedure. I once tried to move the Python CVS to Sunsite
> (or its successors), and gave up after half a year of getting
> nowhere; I'm personally not keen on repeating such an
On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
> Barry Warsaw wrote:
>
> >Public/private keys would be better, and if anybody knows how to set up
> >a Subversion server to use these without having to create accounts for
> >everyone, I think we (the pythong.org admins) would love your help.
>
At 06:39 PM 7/29/2005 -0400, Barry Warsaw wrote:
>But that would still require us to create accounts for every committer,
>right?
No. Just one account. You can have more than one key listed in
authorized_keys, using svnserve --tunnel-user and sshd will select the
right command based on the pub
Barry Warsaw wrote:
> Now's the time I pipe in to remind everyone that Atlassian has offered
> free (as in beer) versions of Jira and Confluence for the Python project
> (actually any open source project). If you haven't used these, they're
> definitely worth a look. Jira is the issue tracker, Co
Well, it has been discussed at multiple times in the past and I have
promised to write this PEP several times, so I finally found enough
time to write a PEP on reorganizing exceptions for Python 3.0 .
Key points in this PEP is the reworking the hierarchy, requiring
anything raised to inherit from
On 7/29/05, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Well, it has been discussed at multiple times in the past and I have
> promised to write this PEP several times, so I finally found enough
> time to write a PEP on reorganizing exceptions for Python 3.0 .
Thanks for getting this ball rolling!
Brett Cannon wrote:
> New Hierarchy
> =
>
> Raisable (new; rename BaseException?)
> +-- CriticalException (new)
> +-- KeyboardInterrupt
> +-- MemoryError
> +-- SystemExit
> +-- SystemError (subclass SystemExit?)
I'd recommend not subclassing SystemExit--there are too m
On 7/29/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > +-- SystemExit
> > +-- SystemError (subclass SystemExit?)
>
> I'd recommend not subclassing SystemExit--there are too many programs
> out there which expect the argument (e.g. sys.exit(3)) to mean something
> specific, but that expec
On Friday 29 July 2005 23:07, Robert Brewer wrote:
> > +-- WeakReferenceError (rename for ReferenceError)
>
> This also has a LookupError feel to it.
I disagree.
LookupError is used when looking for an object within some containing object
according to some sort of key (dict key, index, et
39 matches
Mail list logo
