On 8/8/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I will then assume that you and I have different ideas of what 'mature' means.
So I should then remove your
On Mon, 2005-08-15 at 12:27 -0400, Nicholas Bastin wrote:
On 8/8/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I will then assume that you and I have
Nicholas Bastin wrote:
Not completely. More like -0 at the moment. We need a better system,
but I think we shouldn't just pick a system because it's the one the
PEP writer preferred - there should be some sort of effort to test a
few systems (including bug trackers).
But that's how the PEP
On Sunday 07 August 2005 15:33, Martin v. Löwis wrote:
Ah, ok. That's true. It doesn't mean you can't do proper merging
with subversion - it only means that it is harder, as you need to
figure out the revision range that you want to merge.
If this is too painful, you can probably use
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something. I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system. I
know I'm not the only person with this experience.
compared to
On 8/10/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
in contrast, Perforce just runs and runs and runs. the clients always
do what you tell them. and server maintenance is trivial; just make sure
that the server starts when the host computer boots, and if you have
enough disk, just leave it
Guido van Rossum [EMAIL PROTECTED] wrote:
I'm intrigued by Linus Torvald's preference for extremely distributed
source control, but I have no experience and it seems a bit, um,
experimental.
git, which is Linus' home-grown replacement for BitKeeper, quickly attracted
a development community
[Guido van Rossum wrote]
Also, P4 has *no* command to tell you which
files you've created without adding them to the repository yet -- so
the most frequent build breakage is caused by missing new files.
This one is a frequent complaint from CVS-heads here at ActiveState.
I have a p4 wrapper
Trent Mick wrote:
One feature I like in Perforce (which Subversion doesn't have) is the
ability to have pending changesets.
That sounds useful.
Currently with svn you have to manually
specify those 9 to be sure to not include the remaining one. With p4 you
just say to check-in the whole
On Mon, 2005-08-08 at 19:29, Tim Peters wrote:
Currently with svn you have to manually specify those 9 to be sure to not
include the remaining one. With p4 you just say to check-in the whole tree
and then remove that one from the list give you in your editor with entering
the check-in
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something.
Sure. But so is subversion.
I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system.
I had the last corrupted repository with
Barry Warsaw [EMAIL PROTECTED] writes:
Unfortunately, I don't think we (meaning specifically the collective
python.org admins) have much if any operational experience with
Perforce.
Also (from someone who is on the fringes of the pydotorg admin set): I
don't know that much about subversion
On Sun, Aug 07, 2005, Barry Warsaw wrote:
We'd also have to teach the current crop of developers how to use the
client tools effectively. I think it's fairly simple to teach a CVS
user how to use Subversion, but have no idea if translating CVS
experience to Perforce is as straightforward.
On Mon, Aug 08, 2005, Trent Mick wrote:
Martin:
No. The PEP is only about Subversion. Why should we be looking at Per
Force? Only because Python is Open Source?
Perforce offers free licensing to open source projects.
So did BitKeeper. Linux got bitten by that. We'd need a strong
Trent Mick wrote:
No. The PEP is only about Subversion. Why should we be looking at Per
Force? Only because Python is Open Source?
Perforce offers free licensing to open source projects.
Ok, so I now got it's mature, and it would be without charges.
Given that it is now running against
One feature I like in Perforce (which Subversion doesn't have) is the
ability to have pending changesets. A changeset is, as with subversion,
something you check-in atomically. Pending changesets in Perforce allow
you to (1) group related files in a source tree where you might be
working on
[Trent Mick]
...
There are other little things, like not being able to trim the check-in
filelist when editing the check-in message. For example, say you have
10 files checked out scattered around the Python source tree and you
want to check 9 of those in.
This seems dubious, since you're
On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
One feature I like in Perforce (which Subversion doesn't have) is the
ability to have pending changesets. A changeset is, as with subversion,
something you check-in atomically. Pending changesets in Perforce allow
you to (1) group related files in
[Tim Peters wrote]
[Trent Mick]
...
There are other little things, like not being able to trim the check-in
filelist when editing the check-in message. For example, say you have
10 files checked out scattered around the Python source tree and you
want to check 9 of those in.
This
Who made me the Perforce-bitch? Here I am screaming Subversion!
Subversion! and y'all think I just using that as cover for a p4 lover
affair. :)
[Donovan Baarda wrote]
On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
One feature I like in Perforce (which Subversion doesn't have) is the
On Mon, 2005-08-08 at 17:51, Trent Mick wrote:
[...]
[Donovan Baarda wrote]
On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
[...]
You want to do checkins of code in a consisten state. Some large changes
take a couple of days to write. During which one may have to do a couple
minor things in
Donovan == Donovan Baarda [EMAIL PROTECTED] writes:
Donovan It all comes down to how painless branch/merge is. Many
Donovan esoteric features of version control systems feel like
Donovan they are there to workaround the absence of proper
Donovan branch/merge histories.
It's not
M.-A. Lemburg wrote:
BTW, in one of your replies I read that you had a problem with
how cvs2svn handles trunk, branches and tags. In reality, this
is no problem at all, since Subversion is very good at handling
moves within the repository: you can easily change the repository
layout after the
Phillip J. Eby wrote:
Yeah, in my use of SVN I find that this is more theoretical than actual
for certain use cases. You can see the history of a file including the
history of any file it was copied from. However, if you want to try to
look at the whole layout, you can't easily get to the
Jeff Rush wrote:
BTW, re SSH access on python.org, using Apache's SSL support re https would
provide as good of security without the risk of giving out shell accounts.
SSL would encrypt the link and require a password or permit cert auth
instead, same as SSH. Cert admin needn't be hard if
Fernando Perez wrote:
I know Joe was in contact with the SVN devs to work on this, so perhaps he's
using a patched version of cvs2svn, I simply don't know. But I mention it in
case it proves useful to the python.org conversion.
Thanks for the pointer. It turns out that I could resolve all my
Donovan Baarda wrote:
Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
properly. All the other cool stuff like renames etc is kinda undone by
that. For a definition of properly, see;
http://prcs.sourceforge.net/merge.html
Can you please elaborate? I read the page, and it
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
BTW, in one of your replies I read that you had a problem with
how cvs2svn handles trunk, branches and tags. In reality, this
is no problem at all, since Subversion is very good at handling
moves within the repository: you can easily change the
Donovan Baarda wrote:
What this means is SVN has no way of automatically identifying the
common version.
Ah, ok. That's true. It doesn't mean you can't do proper merging
with subversion - it only means that it is harder, as you need to
figure out the revision range that you want to merge.
If
Martin v. Löwis wrote:
Donovan Baarda wrote:
What this means is SVN has no way of automatically identifying the
common version.
If this is too painful, you can probably use subversion to store
the relevant information. For example, you could define a custom
property on the directory
A
On 8/4/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nicholas Bastin wrote:
Perforce is a commercial product, but it can be had for free for
verified Open Source projects, which Python shouldn't have any problem
with. There are other problems, like you have to renew the agreement
every
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote:
I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system. I
know I'm not the only person with this experience. Sure, you can keep
backups, and not really lose any work, but
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I haven't received any offers to make a qualified statement. I only
know that I would oppose an approach to ask somebody but our
volunteers to do it for free, and I also know that I don't want to
spend my time researching commercial alternatives
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
True, but if we never ask, we'll never know :-)
My question was: Would asking a professional hosting company
be a reasonable approach ?
It would be an option, yes, of course. It's not an approach that
*I* would be willing to implement, though.
aahz == aahz [EMAIL PROTECTED] writes:
aahz I'd rather not rely on licensing of a closed-source system;
aahz one of the points made during the talk was that the Linux
aahz project had to scramble when they lost their Bitkeeper
aahz license
Python is unlikely to throw away its
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M Other non-commercial alternatives are Berlios and Savannah, but
M I'm not sure whether they'd offer Subversion support.
Savannah doesn't offer great reliability or support, at least to judge
by the frequency with which the GNU Emacs and GNU
Nicholas Bastin wrote:
No. The PEP is only about Subversion. Why should we be looking at Per
Force? Only because Python is Open Source?
Perforce is a commercial product, but it can be had for free for
verified Open Source projects, which Python shouldn't have any problem
with. There are
George V. Neville-Neil wrote:
Since Python is Open Source are you looking at Per Force which you can
use for free and seems to be a happy medium between something like CVS
and something horrific like Clear Case?
No. The PEP is only about Subversion. Why should we be looking at Per
Force? Only
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
The PSF does have a reasonable budget, so why not use it to
maintain the infrastructure needed for Python development and
let a company do the administration of the needed servers and
the importing of the CSV and tracker items into their
Donovan Baarda [EMAIL PROTECTED] writes:
This is why I don't bother migrating any existing CVS projects to SVN;
the benefits don't yet outweigh the pain of migrating.
I think they do. I was on dialup for a while, and would have _loved_
Python to be using SVN then -- and given how long diffs
[Martin von Löwis]
The PEP is only about Subversion. I think anything but Subversion is
ruled out because:
- there is no offer to host that anywhere (for subversion, there is
already svn.python.org)
- there is no support for converting a CVS repository (for subversion,
there is cvs2svn)
[François Pinard]
While some say Subversion is the most reasonable avenue nowadays,
others
them told me they found something more appealing than Subversion:
http://www.venge.net/monotone/
The current release is 0.21 which suggests that it is not ready for
primetime.
Raymond
[Raymond Hettinger]
http://www.venge.net/monotone/
The current release is 0.21 which suggests that it is not ready for
primetime.
It suggests it, yes, and to me as well. On the other hand, there is
a common prejudice that something requires many releases, or frequent
releases, to be
M.-A. Lemburg wrote:
True, but if we never ask, we'll never know :-)
My question was: Would asking a professional hosting company
be a reasonable approach ?
It would be an option, yes, of course. It's not an approach that
*I* would be willing to implement, though.
From the answers, I take it
François Pinard wrote:
So, it might be worth at least a quick look? :-)
Certainly not my look - although I'm willing to integrate
anything that people contribute into the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
[Donovan Baarda]
It is true that some well designed/developed software becomes reliable
very quicky. However, it still takes heavy use over time to prove that.
There is wisdom in your say! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW So are you saying that moving to svn will let us do more long
BAW lived branches? Yay!
Yes, but you still have to be disciplined about it. svn is not much
better than cvs about detecting and ignoring spurious conflicts due to
code that
On Sun, 2005-07-31 at 23:54, Stephen J. Turnbull wrote:
BAW == Barry Warsaw [EMAIL PROTECTED] writes:
BAW So are you saying that moving to svn will let us do more long
BAW lived branches? Yay!
Yes, but you still have to be disciplined about it. svn is not much
better than cvs
Donovan == Donovan Baarda [EMAIL PROTECTED] writes:
Donovan Yeah. IMHO the sadest thing about SVN is it doesn't do
Donovan branch/merge properly. All the other cool stuff like
Donovan renames etc is kinda undone by that. [...] This is why
Donovan I don't bother migrating any
M.-A. Lemburg wrote:
The PSF does have a reasonable budget, so why not use it to
maintain the infrastructure needed for Python development and
let a company do the administration of the needed servers and
the importing of the CSV and tracker items into their
systems ?
In principle, this
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
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.
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,
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
1 - 100 of 108 matches
Mail list logo
