[Zope-Coders] Re: [Zope3-checkins] SVN: Zope3/trunk/ Ignore
files/directoriesthat are result of a build process, such
Tres Seaver
tseaver at zope.com
Thu May 13 11:53:53 EDT 2004
Tim Peters wrote:
> [Tres Seaver]
>
>>...
>>+1 for converting any CVS-induced '$Id$' expansions back to '$Id$' in
>>the repository;
>
>
> It won't be enough, because of CVS-specific code like
>
> __version__='$Revision: 1.22 $'[11:-2]
>
> in various places. When "the poor dumb schmuck who has to log in to a box
> and try to diagnose why the system deployed last year is broken", exactly
> what are they relying on? If it's "creative" use of CVS gimmicks (like the
> __version__ defn above), mechanical $Id$ restoration isn't going to help.
I am mostly interested in being able to see the expanded '$Id' in the
docstring of each-and-every module on a deployed system; the
__version__ hackery isn't what I rely on.
>>could we do this in a commit hook, if svn doesn't do
>>it by default?
>
> A one-shot script would probably work better, if this is to be done.
OK. See below for my confusion.
>>+1 for forcing the expansion as part of the release process, so that
>>the tarballs have the expanded strings.
>
>
> Whether keywords are expanded in a file is controlled by that file's set of
> properties. If you give a file F an "expand the $Id$ keyword" property, it
> appears that any way of getting F will expand $Id$; there's nothing like the
> CVS -kk switch (and Philipp reports that merges under svn-- unlike as under
> cvs --aren't confused by keyword expansion).
Hmm, I thought I understood someone to say that this was a client side
setting. If svn knows to ignore expanded keywords when diffing /
merging, then that removes the major pain associated with leaving them
always expanded. In that case:
+1 for enabling expansion on all .py and .c files.
>>-0 for promulgating recommended changes to developers about adding the
>>keyword expansion in their .svnrc.
>
>
> Sorry, I didn't understand that one.
Its moot, anyway, if client-side settings don't matter.
Tres (removing zope-checkins from the follow ups; that list isn't
supposed to be for flamage^H^H^H^H^H^H^Hdiscussion).
--
===============================================================
Tres Seaver tseaver at zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
More information about the Zope-Coders
mailing list