Re: [Python-Dev] r42015 - peps/trunk

[David Goodger]

> Author: david.goodger
> Date: Thu Jan 12 04:33:16 2006
> New Revision: 42015
> 
> Modified:
>peps/trunk/   (props changed)
> Log:
> add external link to Docutils public repo -- always up-to-date

I just deleted the static copy of the "docutils" directory from the "peps"
repository, and added in an external link (svn:externals 'docutils
svn://svn.berlios.de/docutils/trunk/docutils/docutils').  This way, the external
code should always be up-to-date.  You may need to manually delete your
peps/trunk/docutils directory to get this to work though -- SVN leaves
subdirectories behind which hinder the externals update.

Please let me know if this causes any problems.  Thanks.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
>> Author: david.goodger
>> Date: Thu Jan 12 04:33:16 2006
>> New Revision: 42015
>>
>> Modified:
>>peps/trunk/   (props changed)
>> Log:
>> add external link to Docutils public repo -- always up-to-date
> 
> I just deleted the static copy of the "docutils" directory from the "peps"
> repository, and added in an external link (svn:externals 'docutils
> svn://svn.berlios.de/docutils/trunk/docutils/docutils').  This way, the 
> external
> code should always be up-to-date.  You may need to manually delete your
> peps/trunk/docutils directory to get this to work though -- SVN leaves
> subdirectories behind which hinder the externals update.
> 
> Please let me know if this causes any problems.  Thanks.

Question: why do we need docutils in the peps/trunk/ directory
in the first place ?

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

Re: [Python-Dev] r42015 - peps/trunk

[David Goodger]

[M.-A. Lemburg]
> Question: why do we need docutils in the peps/trunk/ directory
> in the first place ?

It's a convenience, so that a separate Docutils download & install
(& maintain) isn't necessary for those who process reST-format PEPs.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> [M.-A. Lemburg]
>> Question: why do we need docutils in the peps/trunk/ directory
>> in the first place ?
> 
> It's a convenience, so that a separate Docutils download & install
> (& maintain) isn't necessary for those who process reST-format PEPs.

Hmm, shouldn't these things be tracked under external/ ?!

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

Re: [Python-Dev] r42015 - peps/trunk

[David Goodger]

On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Hmm, shouldn't these things be tracked under external/ ?!

What do you mean exactly? A new "external" directory?

SVN provides a built-in mechanism for tracking external
repositories, via the "svn:externals" property, and that's
what I used.

--
David 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

Re: [Python-Dev] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> On 1/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Hmm, shouldn't these things be tracked under external/ ?!
> 
> What do you mean exactly? A new "external" directory?

Yes.

> SVN provides a built-in mechanism for tracking external
> repositories, via the "svn:externals" property, and that's
> what I used.

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. Not
sure if it's such a good idea. Branching and tagging
doesn't work with external resources in Subversion,
so things can become inconsistent.

Also, what if you break the code in the berlios repo
or the server is not reachable ? A release copy in the
external/ dir would solve all these issues.

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

Re: [Python-Dev] r42015 - peps/trunk

[Fredrik Lundh]

M.-A. Lemburg wrote:

> AFAIK, this is a first in the Python repository. Not
> sure if it's such a good idea. Branching and tagging
> doesn't work with external resources in Subversion,
> so things can become inconsistent.
>
> Also, what if you break the code in the berlios repo
> or the server is not reachable ? A release copy in the
> external/ dir would solve all these issues.

using svn:external is usually a lousy idea.  using it in a public repository
is a really, really, really lousy idea.





___
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

Re: [Python-Dev] r42015 - peps/trunk

[David Goodger]

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 
___
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

Re: [Python-Dev] r42015 - peps/trunk

[Fredrik Lundh]

Tim Peters wrote:

> Yes. please.  svn:externals should always pin to a specific revision
> (or at least to a "frozen" tag).  Updating to a new revision then is
> just a propedit away (to change the revision number); ditto for
> backing off to an older revision if the newer one has problems.

wasn't the whole point for this exercise to make sure that the included
version was always up to date.  if you pin it to a given version, all we
got from this was a dependence on another SVN server.

(and a can of SVN worms, including issues with locking/cleanup, etc)





___
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

Re: [Python-Dev] r42015 - peps/trunk

[Tim Peters]

[David Goodger]
...
> An alternative is to use svn:externals to link to a specific
> revision (via the -r option);

Yes. please.  svn:externals should always pin to a specific revision
(or at least to a "frozen" tag).  Updating to a new revision then is
just a propedit away (to change the revision number); ditto for
backing off to an older revision if the newer one has problems.

As to the rest, you're using externals in a vanilla way for their
intended purpose, and I have no problems with that.
___
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

Re: [Python-Dev] r42015 - peps/trunk

[Tim Peters]

[Tim Peters]
>> Yes. please.  svn:externals should always pin to a specific revision
>> (or at least to a "frozen" tag).  Updating to a new revision then is
>> just a propedit away (to change the revision number); ditto for
>> backing off to an older revision if the newer one has problems.

[Fredrik Lundh]
> wasn't the whole point for this exercise

Sorry, I don't know what the whole point was.

> to make sure that the included version was always up to date.  if you pin
> it to a given version, all we got from this was a dependence on another SVN
> server.

And very easy updating to a new version ("a propedit away ..."), and
transparency about exactly what it is we're depending on ("revision
12345 of project XYZ").

> (and a can of SVN worms, including issues with locking/cleanup, etc)

I haven't experienced any of that.  I've experienced plenty of
locking/cleanup problems when a project switches _between_ making its
own copies and using svn:externals, but none so long as it sticks to
one way of doing that.  Even on Windows ;-)
___
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

Re: [Python-Dev] r42015 - peps/trunk

[David Goodger]

> [David Goodger]
>> An alternative is to use svn:externals to link to a specific
>> revision (via the -r option);

[Tim Peters]
> Yes. please.

Done.

-- 
David Goodger 



signature.asc
Description: OpenPGP digital signature
___
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

Re: [Python-Dev] r42015 - peps/trunk

[M.-A. Lemburg]

David Goodger wrote:
> 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.

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