Re: [Zope-dev] Re: [Zope-Coders] Re: Question about procedures
martin f krafft wrote:
Do not use hasattr for persistent objects. Use
if getattr(ob, 'absolute_url', None) is None:
Can I read up on the rationale somewhere?
hasattr catches all exceptions and returns false.
Now google for COnflictError ;-)
+ raise TypeError('constructInstance did not return a CMF object.')
Also, check your indentation (should be 4 chars).
Woops.
You should probably run the unit tests before you commit anything.
That also means you should write tests to excercise the changes you're
making, and make sure the tests fail BEFORE you try and fix anything.
For changes which are limited to a file or a subtree I do always
prefer a patch instead of a branch.
I can create a branch and submit patches to you (this is when I wish
zope.org would be using GNU arch). Anyway, since it's probably best
for me not to make changes in the code at present time (being young
in the project and without an assigned field of responsibility),
where do I send potential patches? This list?
Patches should go in collector entries.
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Re: Question about procedures
also sprach Chris Withers [EMAIL PROTECTED] [2005.03.30.1513 +0200]: You should probably run the unit tests before you commit anything. That also means you should write tests to excercise the changes you're making, and make sure the tests fail BEFORE you try and fix anything. Okay. Man, this is fun. :) -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: [EMAIL PROTECTED] eleventh law of acoustics: in a minimum-phase system there is an inextricable link between frequency response, phase response and transient response, as they are all merely transforms of one another. this combined with minimalization of open-loop errors in output amplifiers and correct compensation for non-linear passive crossover network loading can lead to a significant decrease in system resolution lost. however, of course, this all means jack when you listen to pink floyd. signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] brain.getObject and traversal
To try to clarify things even more: The implementation of getObject I checked in a few days ago has the following properties: 1. it checks permissions only on the last step of the traversal, 2. it returns None if for some reason the object cannot be retrieved. Now for the rationale: 1. is necessary in the presence of rights granted deeper in the hierarchy. There's no going around it. 2. is necessary for backward compatibility. *all* the previous implementations of getObject returned None in case of problems. The implementation of 1. looks slightly convoluted but is necessary because we want to leave the details of the traversal (involving __bobo_traverse__, getitem, and checking security with the proper 'accessed' and 'container') to (un)restrictedTraverse. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] brain.getObject and traversal
Florent Guillaume wrote: 2. is necessary for backward compatibility. *all* the previous implementations of getObject returned None in case of problems. This is the only bit I'm asking about, I accept that I'm in the insane minority on the other point ;-) Just because that's what it did before doesn't mean we should leave it like that. I can see absolutely no benefit in returning None over raising a specific error. Also, the original behaviour of getObject, prior to Casey's drastic and unexpected switch to restrictedTraverse(path,None) was to raise Unauthorized, NOT to return None. I first became aware of Casey's changes when I upgraded a production Zope instance and started getting loads of random attribute errors where I'd happilly been dealing with the Unauthorized's before. So, for me, returning None is just plain evil. All it serves to do is mask an exception that's likely to be useful. If people are relying on it returning None, then it's a one line change in their code. Now, the other problem I have with this fix is no tests were checked in for this. We should have tests that verify this behaves as it should, since those tests are likely to be the only formal documentation this issue ever receives ;-) Would anyone object if I wrote tests and changed the implementation to raise exceptions, including Unauthorized, instead of returning None? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] brain.getObject and traversal
Chris Withers wrote:
Just because that's what it did before doesn't mean we should leave it
like that. I can see absolutely no benefit in returning None over
raising a specific error.
Also, the original behaviour of getObject, prior to Casey's drastic and
unexpected switch to restrictedTraverse(path,None) was to raise
Unauthorized, NOT to return None.
You're mistaken. The old code did:
def getObject(self, REQUEST=None):
Try to return the object for this record
try:
obj = self.aq_parent.unrestrictedTraverse(self.getPath())
if not obj:
if REQUEST is None:
REQUEST = self.REQUEST
obj = self.aq_parent.resolve_url(self.getPath(), REQUEST)
return obj
except:
zLOG.LOG('CatalogBrains', zLOG.INFO, 'getObject raised an
error',
error=sys.exc_info())
pass
Which effectively returns None.
I first became aware of Casey's changes when I upgraded a production
Zope instance and started getting loads of random attribute errors where
I'd happilly been dealing with the Unauthorized's before.
You probably had the unauthorized *after* the getObject, when it
returned to you an object you weren't actually supposed to try to access.
So, for me, returning None is just plain evil. All it serves to do is
mask an exception that's likely to be useful. If people are relying on
it returning None, then it's a one line change in their code.
All robust old code had to be able to test for None, because it was
returned in many cases (when indexes got desynchronised, due to
transaction bugs for instance, or manage_beforeDelete swallowing stuff,
or conflict errors happening...). I know I had to add lots in my code.
Now, the other problem I have with this fix is no tests were checked in
for this. We should have tests that verify this behaves as it should,
since those tests are likely to be the only formal documentation this
issue ever receives ;-)
Tests were checked in:
http://cvs.zope.org/Zope/lib/python/Products/ZCatalog/tests/Attic/testCatalog.py.diff?r1=1.22.12.6r2=1.22.12.7
(but zope-checkins list had problems that day, I don't know why, and the
checkin mail never appeared).
Would anyone object if I wrote tests and changed the implementation to
raise exceptions, including Unauthorized, instead of returning None?
Unauthorized in getObject is out of the question, that would be new
behaviour.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] More robust cookie handling
Hi during some testing I did I stumbled over this problem. When a client which is accessing a page on a Zope server sends a _ZopeId with other spelling (e.g. _ZOPEID). Zope does not accept the cookie and (obviously) sends a new value in the answer. According to RFC 2965 and RFC 2109 (defines the Set-Cookie header but is obsolete by RFC 2965) the NAME part of a name-value pair is treated case-insensitive. I'm not sure if this is a issue worth bothering as all user-agents seem to leave the NAME part intact (except my self-written test-suite ;). Changing the behaviour to ignore the case of the name would make it somewhat more robust. If you think it is worth bothering I will open an Issue in the Collector. regards Stefan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] More robust cookie handling
--On Mittwoch, 30. März 2005 17:06 Uhr +0200 S.Aeschbacher [EMAIL PROTECTED] wrote: Hi during some testing I did I stumbled over this problem. When a client which is accessing a page on a Zope server sends a _ZopeId with other spelling (e.g. _ZOPEID). Zope does not accept the cookie and (obviously) sends a new value in the answer. It this a real-world problem? I'm not sure if this is a issue worth bothering as all user-agents seem to leave the NAME part intact (except my self-written test-suite ;). Changing the behaviour to ignore the case of the name would make it somewhat more robust. Are there any browsers that change the name? If not, I don't care :-) -aj pgpyvkiTeW9Gf.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] heads-up: trunk(2.8) and five-integration branch merge
hiya - Just a head's up that I going to try to merge the five-integration branch to the trunk in a bit so Tim can get unblocked on stitching in the newest ZODB. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Disabling FTP by default
I'd like to disable FTP by default, by commenting it out in skel/etc/zope.conf. The reason is that it's better to open as few ports as possible by default. Opinions ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Disabling FTP by default
--On Mittwoch, 30. März 2005 19:54 Uhr +0200 Florent Guillaume [EMAIL PROTECTED] wrote: I'd like to disable FTP by default, by commenting it out in skel/etc/zope.conf. The reason is that it's better to open as few ports as possible by default. Opinions ? Maybe not for Zope 2.7.X..in general..I don't care. -aj pgp3TLM6xNCoP.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Disabling FTP by default
That's what I have been doing. -d On Wed, 30 Mar 2005, Florent Guillaume wrote: I'd like to disable FTP by default, by commenting it out in skel/etc/zope.conf. The reason is that it's better to open as few ports as possible by default. Opinions ? Florent -- Dennis Allison * Computer Systems Laboratory * Gates 227 * Stanford University * Stanford CA 94305 * (650) 723-9213 * (650) 723-0033 fax * [EMAIL PROTECTED] * [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT: defer expression fix
Christian Heimes wrote at 2005-3-28 21:03 +0200: PageTemplates have an undocumented features called defer:. It's a kind of lazy initialization of variables. I've fixed to issues in my tiran-zpt-pydefer branch (svn): * DeferWrappers weren't working inside a python expression because PythonExpr didn't know about them * DeferWrapper didn't cache the result of the expression like ordinary vars do. I would like to merge my branch into 2.7 and 2.8 if I get an ok. Maybe, the feature could get documented as well... An undocumented feature is only half valuable... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Problems with zope 2.7.0 and ZODB (suse 9.1)
Antonio Beamud Montero wrote at 2005-3-29 20:49 +0200:
I get the next errors, when I try to add some of my Product Instances...
(In zope 2.5.0 works well...)
2005-03-29T18:52:47 INFO(0) ZODB Opening database for mounting:
'1110315472_1112115167.490661'
--
2005-03-29T18:52:47 PROBLEM(100) ZODB Failed to mount database.
exceptions.AttributeError ('NoneType' object has no attribute
'getVersion')
Traceback (most recent call last):
File /opt/zope/lib/python/ZODB/Mount.py, line 168, in
_getOrOpenObject
conn, newMount, mcc = self._openMountableConnection(parent)
File /opt/zope/lib/python/ZODB/Mount.py, line 142, in
_openMountableConnection
conn = db.open(version=jar.getVersion())
AttributeError: 'NoneType' object has no attribute 'getVersion'
Apparently, Zope cannot locate the parent ZODB connection.
This can happen, when you create a new subhierarchy containing
a leaf mount point. In such a case, you can commit a subtransaction
to give all new objects a connection before you create the mount point.
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Disabling FTP by default
On Wed, 30 Mar 2005 19:54:39 +0200 Florent Guillaume [EMAIL PROTECTED] wrote: I'd like to disable FTP by default, by commenting it out in skel/etc/zope.conf. The reason is that it's better to open as few ports as possible by default. +1 cheers, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Test failures with five-integration branch merged to head...
I did a merge from the five-integration branch to the head
in a local sandbox, and got the following test failures -
anyone know anything about them?
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Running unit tests from /home/brian/zhead/lib/python
er argument expected, got float
==
ERROR: testBucketGet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testBucketMinKey (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testBucketSet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetGet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetMinKey (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testSetSet (BTrees.tests.test_compare.CompareTest)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/BTrees/tests/test_compare.py, line 32, in
setUp
self.assertRaises(UnicodeError, unicode, self.s)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: UnicodeError
==
ERROR: testCanonicalPath
(zope.app.traversing.tests.test_conveniencefunctions.Test)
--
Traceback (most recent call last):
File
/home/brian/zhead/lib/python/zope/app/traversing/tests/test_conveniencefunctions.py,
line 263, in testCanonicalPath
self.assertRaises(error_type, canonicalPath, value)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
289, in failUnlessRaises
callableObj(*args, **kwargs)
File /home/brian/zhead/lib/python/zope/app/traversing/api.py, line 215, in
canonicalPath
raise ValueError('canonical path must start with a /: %s' % path)
ValueError: canonical path must start with a /: £23
==
FAIL: check_unicode_mixed_unknown_encoding
(TAL.tests.test_talinterpreter.InterpolateTestCase)
--
Traceback (most recent call last):
File /home/brian/zhead/lib/python/TAL/tests/test_talinterpreter.py, line
280, in check_unicode_mixed_unknown_encoding
self.assertEqual(interpolate(text, mapping), expected)
File /home/brian/build/opt/Python-2.3.4/lib/python2.3/unittest.py, line
302, in failUnlessEqual
raise
[Zope-dev] Re: Re: Clarification re: Zope X3.1, 2.8
On Tue, 29 Mar 2005 18:12:51 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Tres] - ZODBGuru uses 'svn rm' to zap the current ZODB on the trunk, replacing it with an 'svn:external' link to your ZODB 3.4 tag; and then tests it (could be an 'svn cp', but I don't see any benefit to maintaining a Zope-specific fork). My problem. It will certainly be done via 9 svn switchs on my local machine first. As explained elsewhere, there are several other possible sources of integration problems here, and I can't know about those before actually trying it. It's possible, e.g., that I'll need to change ZODB 3.4 to worm around them, or switch ZODB to using a different ZConfig, etc. Can't predict here. [snip] - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called). Check. When you use svn:external, it will be copied as is to the tag, so when the external files change, the files in the tag change as well. So a svn cp would be better I guess. Regards, Florian Schulze ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
I'm merging ZODB 3.4 into Zope on a branch. As Tres noted earlier in a checkin comment, a test failure results, because at the ZODB sprint we fleshed out IDataManager and an older Zope3 class claiming to implement IDataManager no longer does. Since Zope trunk doesn't own either the IDataManager definition nor the old Zope3 code, it's unclear how best to proceed: ERROR: testInterface (zope.app.mail.tests.test_delivery.TestMailDataManager) -- Traceback (most recent call last): File C:\Code\Zope\lib\python\zope\app\mail\tests\test_delivery.py, line 46, in testInterface verifyObject(IDataManager, manager) File C:\Code\Zope\lib\python\zope\interface\verify.py, line 93, in verifyObject return _verify(iface, candidate, tentative, vtype='o') File C:\Code\Zope\lib\python\zope\interface\verify.py, line 60, in _verify raise BrokenImplementation(iface, n) BrokenImplementation: An object has failed to implement interface InterfaceClass transaction.interfaces.IDataManager The abort_sub attribute was not provided. An expedient hack would be to castrate ZODB 3.4's IDataManager definition, back to what it was before the ZODB sprint. That's unattractive for obvious reasons (like, e.g., that the old definition lied about what the interface actually is). Current Zope3 trunk will have the same problem with ZODB 3.4 in its MailDataManager class, so that's the right place to fix it. But then the repaired version also needs to be merged into the old Zope3 code Zope trunk is trying to use. The old zope/app/mail/delivery.py also uses the deprecated get_transaction(). Perhaps current Zope3 trunk's delivery.py could just be slammed into the tag used by (or a new tag created for) Zope trunk? get_transaction() is more troublesome than _just_ that, alas: there are about 160 instances of it across the stitched-in lib/python/zope, and Products/Five, code. This causes lots of new deprecation warnings when running the tests. These are easy to repair with 1-2 hours easy editing work, but again Zope trunk doesn't own the lib/python/zope code (where almost all of these appear). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope /tmp file usage
Hi, I am wondering what code in Zope 2.7.5-final potentially may use /tmp directory for temprorary files. I am using zope over webdav and sometimes webdav tries to create a tmp file, of some sort and some parts of the system lock up. There are xml parsers,mime decoders all of which do have binary code bits, so I asking for expert advice, if someone knows of what circuimstances zope would use /tmp directory to create a file... your help will be greatly appreciated. Pavel ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Clarification re: Zope X3.1, 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Schulze wrote: On Tue, 29 Mar 2005 18:12:51 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Tres] - ZODBGuru uses 'svn rm' to zap the current ZODB on the trunk, replacing it with an 'svn:external' link to your ZODB 3.4 tag; and then tests it (could be an 'svn cp', but I don't see any benefit to maintaining a Zope-specific fork). My problem. It will certainly be done via 9 svn switchs on my local machine first. As explained elsewhere, there are several other possible sources of integration problems here, and I can't know about those before actually trying it. It's possible, e.g., that I'll need to change ZODB 3.4 to worm around them, or switch ZODB to using a different ZConfig, etc. Can't predict here. [snip] - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called). Check. When you use svn:external, it will be copied as is to the tag, so when the external files change, the files in the tag change as well. So a svn cp would be better I guess. I don't think so. The point is that each released version of Zope (already) depends on a specific, released version of ZODB; we don't *want* to be copying ZODB into the Zope tree in the repository, because that implicitly creates a fork (i.e., people check into the ZODB copy inside the Zope tree, which is Evil (TM).) When you use 'svn:externals', the referenced package itself is *not* part of the containing checkout; it is managed separately by the svn client (sort of like ESI and page fragments). Tim points out that there are a number of these external dependencies, including ZConfig and zdaemon, which are not directly part of ZODB either: it depends on them in the same way that Zope depends on ZODB. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSy2lGqWXf00rNCgRArecAJ9yZDl7hLH+cAO1eYeIePUB6JzbZQCeJjX7 wXM+tv0oKKpcDFpZd6CQPRI= =Cb8U -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Re: Clarification re: Zope X3.1, 2.8
[Florian Schulze] When you use svn:external, it will be copied as is to the tag, so when the external files change, the files in the tag change as well. So a svn cp would be better I guess. When I make an SVN tag, like repos/main/ZODB/tags/3.4.0a1, the iron intent is that no changes will ever be checked in on that tag. Otherwise the tag would be useless (a tag is meant to capture a frozen point in time). So there's no particular danger in specifying an honest-to-gosh tag in an svn:externals block, although SVN doesn't enforce read-only-ness of tags. If we're worried about that (I'm not), svn:externals also allows specifying a specific revision number to fetch. That should be bulletproof. OTOH, over the next few days, while Jim and I are trying to get other ZODB 3.4 changes made and merged in, it may actually be an advantage to point to ZODB trunk directories, so that ZODB changes show up in the Zope trunk at once too. That's half of how it works in Zope 2.7 (there, changes checked in from anywhere show up everywhere at once). ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
