On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> 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> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com