[Python-Dev] r42015 - peps/trunk (original) (raw)

M.-A. Lemburg mal at egenix.com
Thu Jan 12 20:34:54 CET 2006

David Goodger wrote:

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.

True.

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".

Right, but Subversion doesn't store the revision of the external resource at the time you made the copy, so when you checkout the branch or tag, you'll still get the most recent version of the external resource which can break things, e.g. say you upgrade docutils to Python 2.5, then a checkout of a tag built at a time when Python 2.3 was current would probably no longer work (with Python 2.3).

At least that's how things were documented the last time I had a look at svn:externals - could be that they modified the behavior to make it a little more clever since.

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.

Interesting. Last time I looked these external revisions were not possible (or I overread the possibility).

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

There are two other nits with the external reference:

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?).

I guess that only PSF license covered software should go into the main directories of the repository. Everything else should first go in externals/ and then get copied into the main trunks. It's only one additional step, but will help a lot in the future if we ever have to track the copyright status of things in the main trunks.

This is not an issue for docutils, I guess, since it's public domain, but then again, there are lawyers who believe that there's no such thing as public domain...

http://www.linuxjournal.com/article/6225

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

I guess if you just update to new release versions, then this will be minimal. I, for one, don't mind at all.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Jan 12 2006)

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list