[Zope-Coders] Re: [Zope3-checkins] SVN: Zope3/trunk/ Ignore files/directoriesthat are result of a build process, such

[Tim Peters]

[replying only to zope-coders]

[Tres]
> 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.

OK, Jim sez the __version__ stuff should go too, so I'll drop that.

...

> Hmm, I thought I understood someone to say that this was a client side
> setting.

I believe keyword expansion (whether on or off) under svn has solely to do
with whether the svn:keywords propery is set on a file.  That's a versioned
property, part of the shared repository state.

There's no global way to tell svn that, e.g., all .py files should have
svn:keywords set to Id.  This is unfortunate, but is more general than just
that:  there's no global way to tell svn that all such-and-such files should
have *any* property.  svn:eol-style is like that too.

On the client side, you can enable glob-based "auto props" in your personal
svn config file.  So you can, e.g., tell svn that every .py file *you* add
should automatically get svn:eol-style set to native, and svn:keywords set
to Id.  There doesn't appear to be an effective way to share your config
file settings with others, though -- the svn config gimmicks don't even have
an "include" facility.

The svn developers agreed (even before Jim bothered them about it <wink>)
that svn needs to grow a way to broadcast project-wide config info, from the
repository to developers, but it doesn't have such a thing yet.

> If svn knows to ignore expanded keywords when diffing / merging,
> then that removes the major pain associated with leaving them
> always expanded.

I haven't personally tried that yet, but the docs seem to imply it, and
Philipp von Weitershausen said it worked fine in svn for him.