On Sat, 2005-10-29 at 17:18 -0400, Jim Fulton wrote:
> Chris McDonough wrote:
> > This merge has been done.
> >
> > Since "zopectl test " no longer appears to do the right
> > thing
>
> Could you be more specific?
Your checkin after I did the merge fixed the issue... it could not find
tests belo
Chris McDonough wrote:
This merge has been done.
Since "zopectl test " no longer appears to do the right
thing
Could you be more specific?
cd ~/z2/2/
bin/zopectl test CMFCore
Running tests via: /usr/local/bin/python2.3 /home/jim/z2/2/bin/test.py -v
--config-file /home/jim/z2/2/etc/zope.conf
[Chris McDonough]
> This merge has been done.
Woo hoo! Thank you, Chris!
I since stitched in ZODB 3.6.0b2, which is the most recent 3.6
(internal) release. That didn't seem to create any new problems.
> Since "zopectl test " no longer appears to do the right
> thing
Sorry, never used it, don'
This merge has been done.
Since "zopectl test " no longer appears to do the right
thing and I can't seem to get test.py to run anything except the entire
test suite, I didn't create any new tests because I wouldn't have had
the time to create tests and run them iteratively.
That said, all existin
On Fri, 2005-10-28 at 10:12 -0400, Tim Peters wrote:
> Ah, it's the properties on lib/python that are screwing us here! Chris, throw
>
> svn revert lib/python
>
> into the mix too. That got me unstuck. The problem is that both Jim
> and I (at least) changed the set of externals listed in l
[Tim Peters]
>>> Jim redid the way Zope trunk stitches in Zope3 since you last looked
>>> at this, and that can create some mechanical problems (of the kinds
>>> you're seeing, in fact). The svn docs probably won't help.
>>> Suggestion (which is repetition of what I suggested before this
>>> happe
On Oct 28, 2005, at 9:19 AM, Jim Fulton wrote:
svn:externals suck. A lot. As Tim suggested, you could throw away
this check out and start over. A simpler thing you could do is to
remove the zope directory and do an svn up.
That sounds reasonable, but I've done both of those things and no joy
Chris McDonough wrote:
Jim redid the way Zope trunk stitches in Zope3 since you last looked
at this, and that can create some mechanical problems (of the kinds
you're seeing, in fact). The svn docs probably won't help.
Suggestion (which is repetition of what I suggested before this
happened, bu
[Chris McDonough]
> FWIW, I know a couple of people are depending on this, so here's an
> update.
>
> I am working on merging multidatabase support, but I'm having some
> merge/update troubles (if you're interested in the symptoms, see
> http://www.plope.com/Members/chrism/heres_to_cvs). I suspect
Jim redid the way Zope trunk stitches in Zope3 since you last looked
at this, and that can create some mechanical problems (of the kinds
you're seeing, in fact). The svn docs probably won't help.
Suggestion (which is repetition of what I suggested before this
happened, but we'll gracefully let t
[Tim, trying to comfort a suffering Chris]
> ...
> End of story. Unless you feel you need to make another branch. In
> that case, still do the two steps above first. Then create a new
> branch from Zope trunk, "svn switch" your merged sandbox to that new
> branch, then "svn checkin".
That last
FWIW, I know a couple of people are depending on this, so here's an
update.
I am working on merging multidatabase support, but I'm having some
merge/update troubles (if you're interested in the symptoms, see
http://www.plope.com/Members/chrism/heres_to_cvs). I suspect I'll
work it out, b
I lied. Due to completely preventable circumstances, this merge won't
be done tonight; instead, it will be done tomorrow evening.
- C
On Mon, 2005-10-24 at 16:41 -0400, Tim Peters wrote:
> [Chris McDonough]
> > Thanks for this!
>
> Not required, so long as I get to thank you for finishing it ;
[Chris McDonough]
> Thanks for this!
Not required, so long as I get to thank you for finishing it ;-)
> Looks like that test failure is incidental and not symptomatic of
> changes made to ZODB. I think Tres may have said that it can be
> fixed by merging in a fix from the Five HEAD, but I don't
Thanks for this!
Looks like that test failure is incidental and not symptomatic of
changes made to ZODB. I think Tres may have said that it can be
fixed by merging in a fix from the Five HEAD, but I don't know this
for fact first-hand.
It's encouraging that most of the tests pass but the
Chris, FYI, I stitched ZODB 3.6.0b1 into zodb-blobs-branch, and
changed ZopeDatabase.createDB() to plug database_name into config
instead of passing it to ZODBDatabase.open(). The checkin msg
summarizes test results; since I haven't work on this branch before,
I'm not sure what was expected here (
[Chris McDonough]
> There is a wrinkle about performing this merge that eluded my memory
> until now.
>
> To support multidatabases within Zope, it was reasonable to change
> ZODB.config.ZODBDatabase to support the heretofore
> likely-unused-by-real-world-code "databases" and "database_name" option
[Tim Peters, on multidatabase support in Zope3]
>> ...
>> Jim showed me the Zope3 implementation code and an example today. I
>> found the code easily (on Zope3 trunk), but can't for the life of me find
>> anything there that looks like his example. Jim, where is that?
[Jim Fulton]
> Do you mean
Tim Peters wrote:
[Chris McDonough]
There is a wrinkle about performing this merge that eluded my memory
until now.
To support multidatabases within Zope, it was reasonable to change
ZODB.config.ZODBDatabase to support the heretofore
likely-unused-by-real-world-code "databases" and "database_n
[Chris McDonough]
> There is a wrinkle about performing this merge that eluded my memory
> until now.
>
> To support multidatabases within Zope, it was reasonable to change
> ZODB.config.ZODBDatabase to support the heretofore
> likely-unused-by-real-world-code "databases" and "database_name" option
...
[Chris McDonough]
> Thanks for the offer! I won't be able to visit ZC world HQ tomorrow,
> though unless you'd be there and willing to start around 10pm.
Alas, they're still under the delusion that 10 _am_ is "late" here, so
while I agree 10pm is saner on all counts, I'll be gone before then
Tim Peters wrote:
[Chris McDonough]
I think I may need some remedial SVN help because I don't want to do
this in a stupid way. Hopefully someone will be willing to guide me
through this.
I'll be in FB tomorrow if you'd like to pair on it (while in theory
Jim might object, I think he thinks
There is a wrinkle about performing this merge that eluded my memory
until now.
To support multidatabases within Zope, it was reasonable to change
ZODB.config.ZODBDatabase to support the heretofore
likely-unused-by-real-world-code "databases" and "database_name" options
that may now be passed into
On Tue, 2005-10-18 at 22:21 -0400, Tim Peters wrote:
> [Chris McDonough]
> > I think I may need some remedial SVN help because I don't want to do
> > this in a stupid way. Hopefully someone will be willing to guide me
> > through this.
>
> I'll be in FB tomorrow if you'd like to pair on it (while
On Tue, 2005-10-18 at 11:32 -0400, Jim Fulton wrote:
> Ah, I had forgotten about that. It would be great to merge the mountpoint
> work into the head. There isn't a 2.9 branch afaik.
I think I may need some remedial SVN help because I don't want to do
this in a stupid way. Hopefully someone will
[Chris McDonough]
> I think I may need some remedial SVN help because I don't want to do
> this in a stupid way. Hopefully someone will be willing to guide me
> through this.
I'll be in FB tomorrow if you'd like to pair on it (while in theory
Jim might object, I think he thinks getting this done
Note that I wormed my way around the new ZODB compilation issues by
changing the setup.py file on the zodb-blobs-branch (a minor tweak of
the Zope HEAD).. here's the comment I left to myself.
# added . to EXTENSIONCLASS_INCLUDEDIRS in order to be able to compile
# ZODB HEAD code (which uses qualif
[Tim]
>> I'm copying Fred because he may remember more about this than I do.
>> Fred, do you know of a reason why I can't stitch a newer ZODB into
>> Zope(2) trunk? I have a dim, fading memory of the last attempt
>> failing, and of agreeing in email to wait for the "5 guys" to "do
>> something" be
[It doesn't look like my response went to the zope-dev list; re-sending.]
On Tuesday 18 October 2005 15:43, Tim Peters wrote:
> I'm copying Fred because he may remember more about this than I do.
> Fred, do you know of a reason why I can't stitch a newer ZODB into
> Zope(2) trunk? I have a dim
[Chris McDonough]
>> This is already done on the zodb-blobs-branch. I would be happy to
>> create a mountpoint-branch that does not externally link the ZODB with
>> blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
>> branch if one exists).
[Jim Fulton]
> Ah, I had forgotten abo
[Chris McDonough]
>>> This is already done on the zodb-blobs-branch. I would be happy to
>>> create a mountpoint-branch that does not externally link the ZODB with
>>> blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
>>> branch if one exists).
[Jim Fulton]
>> Ah, I had forgotte
On Tue, 2005-10-18 at 11:32 -0400, Jim Fulton wrote:
> Chris McDonough wrote:
> > This is already done on the zodb-blobs-branch. I would be happy to
> > create a mountpoint-branch that does not externally link the ZODB with
> > blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
>
Chris McDonough wrote:
This is already done on the zodb-blobs-branch. I would be happy to
create a mountpoint-branch that does not externally link the ZODB with
blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
branch if one exists).
Ah, I had forgotten about that. It would b
This is already done on the zodb-blobs-branch. I would be happy to
create a mountpoint-branch that does not externally link the ZODB with
blob support, then merge the changes in to the Zope 2 HEAD (and 2.9
branch if one exists).
November 1 feature freeze, eh? I'd love to get blobs in before this
I was just reminded (by a zope3-dev question) of mount points.
Zope2 has a mount-point capability that requires baboon patching
of ZODB. The ZODB that will be used for Zope 2.9 has a multi-database
feature that would allow a much simpler Zope 2 mount implementation that
would not require even mo
35 matches
Mail list logo