Jim Fulton wrote:
...
Currently, on the zodb33-devel-branch, Zope 2 runs and the great
majority of it's tests pass with NSEC and ZODB 3.3. It you'd like to
see this in action, feel free to check Zope out on the branch and
play with it.
Jeremy pointed out that this wasn't true. I had forgotten
Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-13 15:22 -0500:
...
We need to refactor the way security assertions (permission
settings) are stored and accessed. We need to store required
permissions (__permissions__) on objects. When we need to figure
out roles, we need
place where this
special computation needs to be done.
Also note that I had to get rid of the validateValue call. It's important
that we always pass the name and container to code that needs to get roles.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-22 12:14 -0500:
...
Also note that I had to get rid of the validateValue call. It's important
that we always pass the name and container to code that needs to get roles.
We need name and container only for objects that do not have
their own
Note that this is moot, as I've decided to use a backward-compatible mro.
That is, new-style extension classes will use an mro that is backward
compatible with old-style extension classes. They do *not* use the same
mro algorithm as new-style classes.
Jim
Tres Seaver wrote:
On Mon, 2003-11-24
not to wait for the old-style BTree and intSet compatability
work.
This would mean that old databases would not be useable with the CVS head
in the near term. Would this cause anyone any problems?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Jim Fulton wrote:
Zope 2.8 will not include the old BTree or intSet objects. I plan to
arrange for this not to be a problem for old databases. Somehow, Zope 2.8
will convert these automatically. I haven't done this yet though.
I'd like to merge the new-style ExtensionClass and ZODB 3.3 work soon
to come up with a mechanism for converting
ancient BTrees and intSets. Unfortunately, until a change I checked into
the Zope 2.7 branch on Wednesday, Zope was continuing to use the old
depricated BTrees for a key data structure.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered
Chris McDonough wrote:
On Fri, 2003-11-28 at 09:59, Jim Fulton wrote:
Hi,
I'm just about to start writing the checkin logs for the merge of new-style
ExtensionClass and ZODB 3.3 into the Zope 3 head. I expect the merge to be done
within the next hour or two.
You mean the Zope 2 HEAD, correct
Jim Fulton wrote:
Hi,
I'm just about to start writing the checkin logs for the merge of new-style
ExtensionClass and ZODB 3.3 into the Zope 2 head. I expect the merge to
be done within the next hour or two.
Done!
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
compatability. The algorithm is described in detail
in the docstring for the test_mro test in
lib/python/ExtensionClass/tests.py.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Yuppie wrote:
Jim Fulton wrote:
Done!
Hi Jim!
Here some feedback regarding your checkin.
Thanks!
I tested CMF with Zope HEAD.
These are the issues I ran into:
1.) from ZODB import Persistent, PersistentMapping doesn't work anymore
Maybe Zope 2.7 should have a deprecation warning?
Hm
Steve Alexander and I will be hosting a sprint in Fredericksburg
January 12-14, 2004:
http://dev.zope.org/Zope3/SteveVisitingFredericksburgSprint
A possible topic is Zope 2 to Zope 3 transition and working on
Zope 2.9.
Please let me know if you are interested in participating.
Jim
--
Jim
to be using zopectl start/stop/status instead.
Jim
--
Jim Roepcke
Tyrell Software Corp http://www.tyrell.com/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists
I announced that, for now, The Zope head won't work with old databases.
We are going to have to come up with some code to deal with the
old btrees and intsets.
The good news is that, databases created with Zope 2.7 final should
work. :)
Jim
Jeremy Hylton wrote:
On Thu, 2003-12-11 at 10:24, Sidnei
Sidnei da Silva wrote:
| Jim asked about it on zope-dev, and got no response; see:
|
| Can we forsake database backward compatability on the head for
| a while?
|
| http://mail.zope.org/pipermail/zope-dev/2003-November/021055.html
|
| ...
|
| This would mean that old
. The hard part is walking the object tree. You will need a function that,
|given an object, will return the oids of the objects it references.
|Perhaps Jeremy can help you with that.
I hope so *wink*.
Me too. He's pretty busy. If he can't, I'll try to help.
Jim
--
Jim Fulton
PersistentMapping
is ExtensionClass is installed.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
.
I also had to check in a %$#@ travesty because Data.fs.in still has
references to BoboPOS.
With these changes, I can create a database with 2.6 and open it with the
head.
Thanks Chris for helping us figure out that this was easier than we
thought. :)
Jim
--
Jim Fulton mailto:[EMAIL
? I'd just
never thought of using __of__ or inheritedAttribute or any of the other
EC-specific stuff on a PersistentMapping.
shrug Who knows. I'd rather be safe. It's not that hard.
In any case, we would have needed the fix to handle old pickles
correctly.
Jim
--
Jim Fulton mailto:[EMAIL
in Zope 2
and Zope 3, most notably zope and Zope, with names differing only in
case.
I will also replace the existing Interfaces package with a facade package
that uses zope.interfaces.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
without some background.
I committed that change, but didn't do the original work. I did have a
discussion with Jim which touched on it: the purpose of the change was
to make access via '__getitem__' homogenous across all keys / indexes,
because (as we thought, anyway) there was not any
Tres Seaver wrote:
Jim Fulton wrote:
Tres Seaver wrote:
I will let Jim comment on your use case.
What use case? I missed it. Where is it?
Here is Stuart's original post:
This has the side effect of not passing the name attribute to
my security assertion methods registered via
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 10:03 -0500:
...
Right. The name attribute was intended for attribute-based access.
IMO, it makes no sense to consider key values when doing security
checks.
I will let Jim comment on your use case.
What use case? I missed it. Where
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 17:23 -0500:
...
None should never be passed for attribute accesses. If it is,
then there is a bug. The case of dictionary mapping names to
whatever is for attribute access. We are talking about item/key
access. I haven't seen a use case
Jim Fulton wrote:
Stuart Bishop wrote:
...
It was never intended that the ability to control unprotected sub-objects
by name would apply to items. It was sloppy coding on my part that item
indexes
(yes, indexes, like, say, 1) and keys were passed as names. I can
certainly
understand why
Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 17:23 -0500:
BTW, telling me that an algorithm has changed doesn't constitute
a use case. :) I know that algorithm has changed. I assert that
we don't need the feature that the change broke. I am open
to evidence to the contrary.
Do you have
This would be a good time for people interested and knowledgeable
about packaging systems and who want to influence the direction we
take with Zope 3 to get involved. :)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http
it with the Object scema field type. :)
Should I be contributing code directly to Zope X3's
interface instead of subclassing it?
Absolutely!
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation
propose to make this
a topic of discussion at the upcoming Zope commnity IRC chat:
http://mail.zope.org/pipermail/zope-announce/2004-April/001409.html
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Jamie Heilman wrote:
Jim Fulton wrote:
I propose to move from CVS to subversion for the Zope and ZODB projects;
http://dev.zope.org/Zope3/MovingSCMToSubversion
No complaints from me. I do wonder though... one thing I've noticed
about ZC's CVS usage in the past is that you folks never export
differing only in case is a
bit ugly.
Do we want to consider renaming one or both of these packages
to avoid the conflict?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Jim Fulton wrote:
Zope 2 has a package named Zope. Zope 3 has a package named zope.
Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2.
As things stand, this will require having both Zope and zope packages.
Python can handle this fine, however, it will require putting the packages
Kapil Thangavelu wrote:
On Wed, 2004-04-14 at 09:00, Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
snip
Perhaps we can get more input on whether there's a problem.
A response with a positive sign (e.g. +1, +0, +2
Philipp von Weitershausen wrote:
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live
Jim Fulton wrote:
Jim Fulton wrote:
...
I should have been clearer.
The first question is:
Is it a problem to have two packages with names differing only in case?
I haven't gotten as many responses on this as I expected. I'll try to
summarize
Wrong. People don't find the question useful
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits with the expansion of Zope:
Z
with Zope 3.
I would hate to have imports like z3.app.foo or even z3.i18n.
Why?
What about z.app.foo or z.i18n?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
embarrassing) to document, should the two codebases merge in some unholy
fashion at some point as is on the 2.9 roadmap.
Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361
Stephan Richter wrote:
On Wednesday 14 April 2004 11:08, Jim Fulton wrote:
...
What about z.app.foo or z.i18n?
The shortness of this example is very attractive, but it is still a compromise
in my opinion.
Again, I think educating is easier than anything else. People understand
Marius Gedminas wrote:
On Wed, Apr 14, 2004 at 11:06:37AM -0400, Jim Fulton wrote:
What about renaming the Zope 3 zope package to z.
Examples (from the buddydemo example):
import z.interface
from z.app import zapi
from z.app.event import publish
from z.app.event.objectevent import
Jim Fulton wrote:
Jim Fulton wrote:
...
Give the responses. I need to recast my question as a selection
among alternatives. But, before I do that, we will need to consider
alternatives a bit more.
OK, here's another.
What about renaming the Zope 3 zope package to z.
- It fits
into packages, so that
'zope' doesn't get excessively broad.
I think the depth vs breadth balence we have now is about right.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Sidnei da Silva wrote:
On Thu, Apr 15, 2004 at 08:59:44AM -0400, Jim Fulton wrote:
| So, what about this:
|
| zope.component
| zope.interfaces (?)
| zope.configuration
| zope.testing
| zope.schema (soon-to-be-dead?)
|
| - All move to 'ca.*'
|
| Most of this has nothing to do with the component
the component architecture is called z
No, the component architecture is z.component.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Barry Warsaw wrote:
On Thu, 2004-04-15 at 09:25, Jim Fulton wrote:
From the zope package README.txt:
Zope Project Packages
The zope package is a pure namespace package holding packages developed as
part of the Zope 3 project.
Generally, the immediate subpackages of the zope package
Based on recent discussions, I've created a proposal:
http://dev.zope.org/Zope3/RenameTheZopePackage
to rename the zope package to z. Unless there are strong
objections, we'll do this after we move the Zope repository head to
subversion at the end of the month.
Jim
--
Jim Fulton
to Zope 2 and other ZODB
applications.
Comments are welcome.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
to the proposal that the scope includes the sort of
scenario you described.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Chris Withers wrote:
Jim Fulton wrote:
Lennart Regebro wrote:
From: Jim Fulton [EMAIL PROTECTED]
Initially, I propose to move just the repository heads. Maintenamce
branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS.
What is the rationale behind not moving it all?
- Reduce risk
Jim Fulton wrote:
Based on recent discussions, I've created a proposal:
http://dev.zope.org/Zope3/RenameTheZopePackage
to rename the zope package to z. Unless there are strong
objections, we'll do this after we move the Zope repository head to
subversion at the end of the month.
I've gotten
on Zope 2 stopped?
No. ZC still puts more work into Zope 2 than into Zope 3.
I expect that to continue for some time.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
approach is that, having built what we've
built, we'll be able to take advantage of that code in the current platform.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com
specific about your concerns?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev
are building production apps with it now,
even though there isn't a production release. That's why we're working
very hard to make a production-quality release of what we have now, even
though it doesn't do everything that it needs to do in the long term.
Jim
--
Jim Fulton mailto:[EMAIL
are a way for people to find out when somethings
coming.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
of the leaders
of the Zope 2 community are involved in Zope 3 and using it.
These people are application developers.
Jim,
we native german speakers tend to be much more direct and phrase dings
more bluntly the you americans do.
In german I read Maik's statement as a strong opinion but never as an
insult
Martijn Faassen wrote:
Jim Fulton wrote:
I'm surprised to read this. Could you be more specific about your
concerns?
Did you read Andreas Jung's mail? He was pretty specific, but I had to
hunt around as in my mailreader his reply had broken the thread.
I was responding to Philipp, not Andreas
Jamie Heilman wrote:
..
Oh, and about Maik's comment that ZC is the bottleneck in Z2 dev--Jim,
I think it was Andreas
you might not agree with Maik, but hidden security bugs over a year old
aren't something the rest of the community can do anything about.
Are you suggesting that we hid them
would be responsible for
planning and executing the release, including bug-fix releases
for that base release. That team could establish the policy for
changes to that release, possibly including vetting fixes.
It would be great if someone would volunteer to update the process doc.
Jim
--
Jim
this after we do the svn conversion.
I *hope* to do that next week.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Martijn Faassen wrote:
Hey there,
I understand from:
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan
Zope 2.8 is now planned for june.
This is, of course, a function of people's availability to help.
I still need to fix ZClasses, and I need to get through
that we have succeeded.
This exactly the sort of feedback we need.
Thanks.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Philipp von Weitershausen wrote:
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Why would they switch to Zope 2.8 if not for the component architecture?
To stay current? To get MVCC? To get new-style extension classes, and
thus access to many modern Python features. Later releases
Philipp von Weitershausen wrote:
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release
policy in Zope 2 and its future regarding maintainance and support. I
have to say that I share some of his skepticism regarding Zope 2. I
personally have never fully
Chris Withers wrote:
Jim Fulton wrote:
FYI, there's a similar zip file now containing the same kind of thing
for a
current Zope3 checkout (s/Zope2/Zope3/ in the URL).
If this is good enough for people trying to work from CVS on Windows,
let me
know and I'll update them from time to time
on irc.freenode.net #zope-dev...
I don't mind being the official announcer and hassler if people are
happy for me to have that role :-)
+1
Doesn't really need to be official though, does it?
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED
in:
http://svnbook.red-bean.com/svnbook/ch07s04.html
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
I'd like to plan to convert the repository heads to subversion this Wednesday.
I'll confirm this on Tuesday. It will be best of no one does any work on
the head on Wednesday.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
selectively.
Initially, we'll convert only parts needed for Zope 2, Zope 3 and ZODB.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
/trunk Zope3
for public checkouts.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev
Fred Drake wrote:
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote:
cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
That should be:
svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
cvs co http://svn.zope.org/repos/Zope3/trunk Zope3
and this would be:
svn co http
with the
cvs-to-svn-conversion tag. If you have outstanding head work, you should be
able to update to that tag and then use cvs diff to generate patch files to
be applied to subversion checkouts.
Jim
Jim Fulton wrote:
I'm about to begin the conversion now. Please don't make any more
changes
There is a problem with the public subversion access. The 'svn' urls
are currently disabled. 'svn+ssh' urls are still working as is web access.
I expect to have this problem resolved today.
Jim
Jim Fulton wrote:
The conversion is done. All trunk development should be done in the
subversion
I'm about to begin the conversion now. Please don't make any more changes to the
Zope, Zope3, ZODB, ZConfig, zLOG, or zdaemon CVS heads.
Jim
Jim Fulton wrote:
I plan to do the transition tomorrow, Tuesday may 11.
I'll begin at 10am US/Eastern and be done by 5pm US/Eastern.
During this time, I
Jim Fulton wrote:
There is a problem with the public subversion access. The 'svn' urls
are currently disabled. 'svn+ssh' urls are still working as is web access.
I expect to have this problem resolved today.
This has been resolved. 'svn' urls are enabled again.
Jim
--
Jim Fulton
done, I will remove all files from the
heads of the preojects in CVS, except README.txt files giving subversion access
instructions.
Jim
Jim Fulton wrote:
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line
endings.
I suspect
will
remain in CVS.
I think that option 2 provides a nice compromise. The main disadvantage
of it is that it will leave current development branches high and dry.
I'm not sure how big an issue this is. In theory, these could be committed
to the subversion heav via patch files.
Thoughts?
Jim
--
Jim
/br2
...
/proj2
/br1
/br2
...
But that would require inclusion of a /trunk dead chicken
in checkouts:
svn co svn+ssh://svn.zope.org/repos/trunk/ZODB
which seems unnecessary to me.
Thoughts?
Jim
--
Jim Fulton
Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:23, Jim Fulton wrote:
2. Convert the mainline history, but leave off the branches.
Would this mean we'd lose the log messages too?
Yes, you'd lose the branch log messages.
If so -1 because often
merge messages aren't very helpful. merged foo-bar
Jim Fulton wrote:
Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:23, Jim Fulton wrote:
2. Convert the mainline history, but leave off the branches.
Would this mean we'd lose the log messages too?
Yes, you'd lose the branch log messages.
If so -1 because often
merge messages aren't very
Barry Warsaw wrote:
On Mon, 2004-04-26 at 15:42, Jim Fulton wrote:
The reason that I hate merge messages like this is that I find it
very difficult to find the branch checkin messages in thye log. It's
possible, but so difficult that I generally would rather not
bother.
I agree, but history
Jim Fulton wrote:
I'm working on the cvs to subversion conversion for the ZODB, Zope 2, and
Zope 3 projects. I'm currently doing the conversion of the full history
with
tags and branches. This is taking a long time and creating a huge
repository, which is OK, but, do we really need that much
agreement to us in
one of 3 ways:
- Ordinary mail to:
Zope Corporation,
513 Prince Edward Street
Fredericksburg, VA, USA, 22401
- Fax to 1.703.995.0412
- Email a scanned form to: [EMAIL PROTECTED]
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
Jim Fulton wrote:
Tomorrow, as planned. I'm going to move the main development branches for
Zope 2, Zope 3, and ZODB to subversion. I will start the move at 10am
US/Eastern time tomorrow. I plan to be done before 5pm US/Eastern time.
During this time, I ask that no one make checkins to the CVS
property except cvs2svn:cvs-rev.
So, given your explanation, why did Tim get bad line endings I wonder.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
Paolo Invernizzi wrote:
Jim Fulton wrote:
None. The files were not added or imported. They were input
via cvs2svn, which uses dump files. The cvs2svn utility apparently
doesn't set mime types, or any other property except cvs2svn:cvs-rev.
So, given your explanation, why did Tim get bad line
Tim Peters wrote:
[Jim Fulton]
...
You will be able to do read-only anonymous checkouts like so:
svn co svn://svn.zope.org/repos/main/project/trunk
For example:
svn co svn://svn.zope.org/repos/main/ZConfig/trunk
FYI, I tried that on Windows (XP), and it worked fine.
One glitch, which may
to this for a month
or so. If you want to help, let me know.
The next time we try this, I'll build a longer testing period
into the plan, and, probably a more gradual migration (e.g.
only move the ZODB head first.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO
://svn.zope.org/repos/main/project/trunk
or, to do a writable checkout:
svn co svn+ssh://svn.zope.org/repos/main/project/trunk
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http
Max M wrote:
Jim Fulton wrote:
I've done a conversion of a snapshot of the CVS database from yesterday.
This is just to allow people to play with subversion and see what the
respoitory
might look like when we do cut over.
To browse the respository:
http://svn.zope.org/
It seems to have
a sprint means getting in touch with the right people to
organize a sprint accomodation, and communicating the sprint time and
place to all developers. It's also a good idea to get in touch with
Jim about potential sprint topics.
I can do that. ;)
If nobody steps up to organize a sprint
, then I
think we could move forward with the transition sooner, perhaps the week after next.
(I still need to arrange for setting the property during conversion, but I think
I can manage that.)
Jim
Jim Fulton wrote:
Tim Peters wrote:
[Jim Fulton]
...
You will be able to do read-only anonymous
Jim Fulton wrote:
...
http://subversion.tigris.org/servlets/BrowseList?list=usersby=threadfrom=184061
Ken pointed out that the links on this page don't work. :( Sigh
Here are links that do work:
http://subversion.tigris.org/servlets/ReadMsg?list=usersmsgNo=10439
http://subversion.tigris.org
is to *finally* support cross database
references.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Lennart Regebro wrote:
Jim Fulton wrote:
Thoughts?
Only that the Subversion people are wrong. Ad-hoc is not good enough. It
must be able to be configurable on the server.
You may be right. This was certainly my initial reaction. I think, though,
that we should at least try handling
Jim Fulton wrote:
Sorry for the false start.
I totally missed a flaw in subversion's handling of text-file line endings.
I suspect that this is fixable, but it's not going to be fixed today.
I think that this issue has been resolved. I have updated my cvs to svn
conversion software to set
= persistent.wref.ref(foo)
Anyway, you ask a reasonably question. Let's continue this discussion after
I write a proposal for cross-database references.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation
carelessness
(things like just using unix path seperators rather that os.path.join,
etc)...
shrug
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http
401 - 500 of 1423 matches
Mail list logo
