On Fri, 2004-04-30 at 10:48, Philipp von Weitershausen wrote:
But, as the -kb property in CVS has shown, newbies tend to forget these
things. Then again, setting svn:eol-style after a file has been added to
svn is easier than getting -kb on a file that's already in CVS.
I often have to cvs
On Fri, 2004-04-30 at 11:33, Jim Fulton wrote:
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
Neither do many of the next in thread and previous in thread links.
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? If so -1 because often
merge messages aren't very helpful. merged foo-bar-branch to head
would suck if you couldn't at least see the log
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 is history, so we
On Mon, 2004-04-26 at 15:48, Tim Peters wrote:
[Jim]
I read some subversion docs over the weekend, and so am sufficiently
prepared to live with the oddities of a standard subversion layout. I
think that if you make a non-standard layout, then everyone coming to, or
going from, Zope from/to
On Tue, 2004-04-20 at 10:01, Chris Withers wrote:
This discussion smells like that string should be computed from introspection.
Why can't it be computed from introspecting whatever code called the log method?
You probably could do it via sys._getframe(). I'm not sure you should
though. ;)
On Tue, 2004-04-20 at 15:46, Fred Drake wrote:
On Tuesday 20 April 2004 12:08 pm, Jim Fulton wrote:
What do people think about alternative 4?
+1
Okay, add me to the chorus: +1
-Barry
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 should be
On Thu, 2004-04-15 at 10:23, Jim Fulton wrote:
Each separately distributed package will have a DEPENDENCIES.cfg that is
created by hand and that *constrains* dependencies on other packages. It
makes explicit the intended dependencies. Dependencies not listed here
are bugs. Adding depenencies
On Thu, 2004-04-15 at 11:39, Casey Duncan wrote:
Additionally (and Jim and I have discussed this amongst ourselves) I
feel strongly that the dependancies should be enforced by tests.
Good point.
The dependancy tests might need to be separate from unittests because
they would probably
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote:
Because in general I don't like version numbers in the path. I also think that
zope is the only name that is 100% right on. Everything else is a
compromise I would try to avoid. We will be sorry about it later, when many
more people run
On Tue, 2003-12-30 at 13:48, Fred L. Drake, Jr. wrote:
My usual response has been that it can already be done reasonably
using something like:
%define topdir /some/path/to/the/top/of/my/tree
%define logdir $topdir/log
some-logfile $logdir/interesting.log
On Mon, 2003-12-29 at 00:12, Fred L. Drake, Jr. wrote:
I'm going to describe each issue in a separate email, including why
I've changed my mind about them and what the consequences are for
ZConfig users. Please respond to these messages if you think the
proposed changes will have a negative
On Mon, 2003-12-29 at 00:28, Fred L. Drake, Jr. wrote:
ZConfig currently requires that derived section types not specify a
keytype attribute, used to change the interpretation of the keys.
The intent is to ensure that keys defined in the base section type
will still be recognized and
On Mon, 2003-12-29 at 12:52, Fred L. Drake, Jr. wrote:
Changing the keytype allows different interpretations for keys. The
only thing required of keys at the lowest level of the parser is that
keys do not contain spaces. The basic-key datatype is used to
create a case-insensitive handling
On Mon, 2003-12-29 at 15:07, Fred L. Drake, Jr. wrote:
- $ substitutions in defaults
Often, my defaults for keys can be expressed in terms of $
substitutions that are more general for my system. Unfortunately,
there doesn't seem to be any way to make this work. ZConfig
16 matches
Mail list logo
