On May 25, 2005, at 6:32 PM, Michael L Brown wrote:
>
> If a user config had autoprops set such that all *.c files are
> given the
> svn:keywords property, when is that exactly accomplished?
I think at the time of 'svn add blah.c'
> Because the
> user's working copy will have the keywords property set against the
> file that was just initially checked in. Because we don't trust
> the user
> to have an updated config file (as another user agreed with), can't a
> hook script be written to ultimately do the exact same thing that SVN
> does, i.e., when the new file is committed, the keyword property is
> set (if it is supposed to get set) and that the working copy in the
> user's work area will indicate that the property is set, without
> having
> to do a "svn update" on the file just committed?
No, the hook script can't update the user's working copy.
For that reason the standard practice is simply to check if the
properties are set correctly and reject the commit with an
appropriate error message using the hook script.
>
> That is why I am strongly lobbying for a master repository config
> file.
> But, even the master config file has a problem, because pretty much
> all
> of our Unix scripts do not have an extension, so they can't be
> wild-carded in the config file, like *.c, *.h ,etc.
That is an entirely different issue with the config files that I
would like to see addressed as well.
It should be possible to have a local hook script or something run on
the file at the time of the 'svn add', though that doesn't address
the issue of having a standard set of server enforced settings.
> That means a
> user config file ain't gonna work either. Having our users
> remember to
> apply the svn:keywords property against text files is ultimately going
> to be a bust. I'd rather have a hook script do it automatically
> behind the scenes.
Have your hook script reject the commit with a message telling the
user they need to update their config file from the master copy
located in your repository somewhere. (Also mention the files and
missing properties so they can easily correct the current situation.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 26 14:05:55 2005