[Python-Dev] r42015 - peps/trunk

[M.-A. Lemburg]

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:

* connecting to a server that people probably don't
  recognize as being an official Python source and thus
  probably don't trust right away (though this is well
  hidden by subversion, firewall software will alarm the
  user)

* being able to download the complete repository of Python
  with all the history - since the external resource is not
  part of the history, users would have to track down
  the repository of the external resource (and this might
  not be readily available for download)

>> 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 ! ::::