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
standard
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 accounts with
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 the
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 conversion
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 don't
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 need to
type one
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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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 Python.
[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 clear
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 doing
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
sink
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 took several
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
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 your
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 passwords.
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
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
moving
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 remotely
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 machine
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 plain text
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
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 directories,
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.
I'll
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
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,
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!
(I
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 expectation
33 matches
Mail list logo
