[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Setting up the Configuration File

From: Weintraub, David <David.Weintraub_at_ilex.com>
Date: 2005-03-31 19:03:24 CEST

Okay, I now know that I can't setup a config file for a server in order to
make sure that the svn:keywords property is set.

However, I've been playing around with the pre-commit hook, and have come up
with the following little tidbit of Kornshell code which looks at all the
files that are being changed, and checks the svn:keywords property to see if
it is set:

svnlook changed -t $TXN $REPOS | while read type path
do
    prop=$(svnlook propget -t $TXN $REPOS svn:keywords $path 2> /dev/null)
    if [ ! $prop ]
    then
        print -u2 "No property svn:keywords is set for $path!\n"
    else
        print -u2 "Keywords property is $prop"
    fi
done

This means I can prevent someone from committing their changes if the
svn:keywords property isn't set for a file. I could even give the command
they need to run.

However, what I'd really like to do is set the svn:keywords property for the
user, but I can't figure out how to do that. The commit script is running on
the server and not on the client who has the working directory checkedout,
so I can't do an "svn propset". But, neither svnadmin nor svnlook allow me
to set a property.

I'm pretty new to Subversion and might be missing something fairly obvious.
Is there a way for the server to "fix" this transaction and set the
svn:keywords property for the user?

-----Original Message-----
From: William Nagel [mailto:bill@stagelogic.com]
Sent: Wednesday, March 30, 2005 8:35 PM
To: Weintraub, David
Cc: users@subversion.tigris.org
Subject: Re: Setting up the Configuration File

On Mar 29, 2005, at 3:00 PM, Weintraub, David wrote:

> We have recently established a policy that one of our project will
> allow for automatic keyword expansion for $Id$. This is not true for
> other projects.
>
> I understand that I can set this in the "config" file by putting in
> the following lines:
> [miscellany]
> enable-auto-props = yes
>
>  [auto-props]
> * = svn:keywords=Id
>
> I also understand that the default Subversion config file is
> /etc/subversion/config.
>
> What concerns me is that we have two projects, one where we want to
> allow all users to have $Id$ keyword expansion and in another project,
> we do not necessarily want to enable this expansion. Both projects are
> using the same Apache webserver but two different archives.

As far as I know, there is no way to direct enable-auto-props to a
specific repository.

>
> I am also concerned that the /etc/subversion/config directory is for
> the clients that are on that machine and not the clients who may not
> be on that machine, but use the Subversion archive on that machine.

The 'config' file is a user configuration file that configures the
behavior of the svn client, not the repository. /etc/subversion/config
sets defaults for all of the clients local to a given machine, but that
default can be overridden by each individual user's ~/.svn/config file.

>
> How do I set up our archive so that http://switchblade/project1
> automatically allows all files to have $Id$ keyword expansion while
> http://switchblade/project2 doesn't do that?

There really isn't any good way to do what you want to do. One
possible hack would be to give all of your users a special script for
doing file adds that would wrap the 'svn add' command and automatically
perform the property addition if the file is being added to project1.
It would be a bit of a pain, since you'd have to distribute special
scripts/binaries to each user, and it would also be a little bit
error-prone, since users would still be able to use 'svn add' by
itself. If you really need the auto-props differentiation, though, it
may be a workable solution.

Hope that helps,

-Bill
Received on Thu Mar 31 19:07:49 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.