[Python-Dev] r42015 - peps/trunk

David Goodger goodger at python.org
Thu Jan 12 18:04:51 CET 2006


On 1/12/06, M.-A. Lemburg <mal at egenix.com> wrote:
> I know, but I wouldn't expect SVN to query other servers
> than svn.python.org inside the standard repository
> directories.
>
> AFAIK, this is a first in the Python repository.

True, and worth discussing.  Luckily the PEPs repository is a
low-traffic, non-core area, so it's not urgent.

> Not sure if it's such a good idea.

>From my point of view, it's a time-saver.  No more manual updates!
They were a pain, and rarely got done.

> Branching and tagging
> doesn't work with external resources in Subversion,
> so things can become inconsistent.

How so?  The "svn:externals" property is treated the same as any
other, and is copied along with everything else by "svn copy".

> Also, what if you break the code in the berlios repo
> or the server is not reachable ?

If the code in the repo ever breaks, it will be fixed within minutes.
The server being unreachable is only a problem for initial checkouts;
updates will just keep the code that was already there.  In my
experience, the berlios.de SVN server has rarely been unreachable.  If
there's a problem, we can always back out the svn:externals property
and install the package.

That having been said, I do see the value of installing a packaged
release.  We just released Docutils 0.4 a few days ago; I could
install that statically.  An alternative is to use svn:externals to
link to a specific revision (via the -r option); I could link to the
0.4 release revision.  This would solve the repo-breakage issue, but
not the server-unreachability issue.

I don't think these issues are major, but I wouldn't mind terribly if
we decide to go with a static install.

> A release copy in the
> external/ dir would solve all these issues.

That's basically what we had before (except no explicity "external"
directory), but it was always out of date.  The "docutils" package was
directly in the trunk, for ease of import by the pep2html.py front end
(easy to work around, but why bother?).

Another minor nit with the old way: updates "polluted" the
python-checkins list.

--
David Goodger <http://python.net/~goodger>


More information about the Python-Dev mailing list