[christian]
That said , since ZEO ends up doing multiple python interpreters its
possibly the more reliable approach to take advantage of SMP linux.
please point out any flaws in my thought process .
SMP is not doing any good for you when not running multiple Python
processes. The GIL doesn
Tim Peters wrote:
One glitch, which may be all over the place: some of the "text files" got
checked out with Windows line ends, but most did not. For example, 14 of
the 19 *.txt files in ZConfig ended up with Windows line ends, but none of
the 37 *.py files did.
Ack, no, none of the checked-out
sathya wrote:
What about threads on linux ? will binding a process to a CPU also mean
all threads spawned by the process are also bound to the same processor
? I am not aware of linux support for binding threads to a CPU so I
guess it does not matter .
For a full discussion of this and oter SMP
All,
We will *not* to the cvs to subversion transition today. Feel free to
check in against the cvs head.
Tim,
Thanks for trying this out.
It looks like we're not ready to convert yet. :(
We need to sort out the issues you raised. Clearly, the move to subversion is
going to take longer than I'
Paolo Invernizzi wrote:
Tim Peters wrote:
One glitch, which may be all over the place: some of the "text files"
got
checked out with Windows line ends, but most did not. For example, 14 of
the 19 *.txt files in ZConfig ended up with Windows line ends, but
none of
the 37 *.py files did.
Ack, n
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 endings I wonder.
Jim
I've
[Jim]
...
> So, given your explanation, why did Tim get bad line endings I wonder.
The relevant info is scattered all over the docs. Bottom line is that svn
does line-end conversions if and only if the svn:eol-style property on a
file is set to a valid value (where "native" is what's wanted most
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 endin
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//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 be all
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 can't afford to spend much more time on this before Zope X3.0
gets to beta, so I don't expect to get back to this for a mon
From: "Jim Fulton" <[EMAIL PROTECTED]>
> I found this to be so unbelievable, that I had to resoearch it myself.
[...]
> unbelievable, I couldn't help it.
> > I think we'll have to develop a standard set of config file settings
like
> > that for committers to add to their personal svn configs --
E
Jim Fulton wrote:
I think the "real" answer, the answer that the svn (and arch) developers
believe
in the heart of hearts is that windows users should be using tools that
understand,
well, understand and always produce Unix line endings.
Is it practical to require windows users to use tools tha
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/
To do a read-only checkout:
svn co svn://svn.zope.org
>>> I think we'll have to develop a standard set of config file settings
>>> like that for committers to add to their personal svn configs --
[Lennart Regebro]
> Eh. WHAT!?! OK, that there are settings like these, but aren't they
> configured on the server?
> They are CLIENT side? That is very wei
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 some kind of dns p
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 some
Me too! :(
Strangely, it worked fine earlier today...
Stefan
On Mittwoch, Apr 28, 2004, at 21:01 Europe/Vienna, Jim Fulton wrote:
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Jim
--
The time has come to start talking about wh
I was just able to browse it via ViewCVS...
On Wed, 2004-04-28 at 15:01, Jim Fulton wrote:
> 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
> >> r
Oops, but now I can't!
On Wed, 2004-04-28 at 15:01, Jim Fulton wrote:
> 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
I pounded on it a few minutes before responding.. I'm not having problems...
--
Thanks, Scott
-Original Message-
From: Jim Fulton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 28, 2004 2:02 PM
To: Max M
Cc: [EMAIL PROTECTED]
Subject: [Zope-dev] Re: Demonstration subversion repository c
Jim Fulton wrote:
Hm, I can get to it from a machine outside of ZC or Zope.org.
Is anyone else haveing troubles getting to it?
Now it's back up.
C:\>ping svn.zope.org
Pinger cvs.zope.org [12.155.117.30] med 32 byte data:
Svar fra 12.155.117.30: byte=32 tid=100ms TTL=53
Svar fra 12.155.117.30:
> For line translations, it appears that svn (and CVS) do that purely on the
> client side, and that makes sense:
Yes, but I'm pretty sure there are default settings for which files that
should be treated as binary on the server side in CVS. At least I rember
setting it up. :´)
Max M wrote:
Now it's back up.
And it works fine. Text files are in Unix format. As expected.
regards Max M
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lis
On Wednesday 28 April 2004 04:01 pm, Lennart Regebro wrote:
> Yes, but I'm pretty sure there are default settings for which files that
> should be treated as binary on the server side in CVS. At least I rember
> setting it up. :´)
Yes, this is specified in the CVSROOT/cvswrappers file.
-Fre
Martijn Faassen wrote:
Martijn Faassen wrote:
So far nobody has stepped up to organize a Zope 3 sprint before and/or
after EuroPython this year.
If you want to organize a sprint please send a mail to
[EMAIL PROTECTED]
No such mail was sent as far as I can see.
I just sent it.
Organizing a sp
Paul Winkler wrote at 2004-4-26 17:45 -0400:
>On Mon, Apr 26, 2004 at 07:47:39PM +0200, Dieter Maurer wrote:
>> Our minimal tool usage is probably: "Actions", "Membership",
>> "Skins", "Types", "Workflow".
>
>I'm curious... do you use these with sites that are not
>in any other way based on CMFCore
Dario Lopez-Kästen wrote:
thanks much for the info.
turns out that the updated kernel rpms for RH8 and RH 9 2.4.20-28.8smp
contain the patch for cpu affinity as well
at this point seems like a good idea to deploy ZEO and bind each client
to a processor and test it out ,hopefully with a 4way sm
[Jim]
>>svn co svn+ssh://svn.zope.org/repos/main//trunk
[Tim]
> Is that supposed [to] work already? All I've been able to get out
> of it is, e.g.,
>
> C:\Code>svn co svn+ssh://svn.zope.org/repos/main/ZConfig/trunk szc2
> svn: Connection closed unexpectedly
>
> where the error msg app
28 matches
Mail list logo