William Nagel <bill@stagelogic.com> wrote on 05/25/2005 03:51:47 PM:
> > Now I have to write a hook script, or more, to do that work for us.
> > The note mentions that you have hook script examples. Are your
> > examples
> > to the point that I can use them to figure out what I need to do,
> > i.e.,
> > check that it is a text file of the type that I would check for and
> > then set the property? Plus, make sure that the user didn't set the
> > property by mistake (which we didn't do with CVS)?
>
> The book does have several hook script examples of varying complexity
> (including a couple that are fairly involved). Unfortunately, I
> don't have an example in the book that specifically addresses your
> issue or one like it. I do talk about the things you can/can't do in
> hook scripts though, as well as the ways the various SVN tools can be
> used inside of a hook script.
I didn't really expect an example dealing with my problem. That would
have
been like hitting the Powerball lottery :-) The idea would be to take
what you have as examples and apply that to the problem.
> For the most part, I encourage using hook scripts to validate policy
> and reject commits that don't follow the appropriate policy with an
> error message that explains what needs to be done. Although you can
> use a post-commit hook to perform a second commit to make the
> property change, I think that adds an extra layer of complexity and a
> failure point (the client needs to update to get the version of the
> file that has the property set).
Maybe I need to understand the process a little better.
If a user config had autoprops set such that all *.c files are given the
svn:keywords property, when is that exactly accomplished? 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?
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 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.
If the master config file had an inverse check, i.e., if the file doesn't
match a set of criteria, apply the property. That would make checking
in of known binary files so much easier.
> > Something just came to mind that I didn't think of before... would it
> > be easier to look for the fact that it is a binary file and make sure
> > that the proprty isn't set and just set it for all other files? I
> > have a list of all the binary types that we have, since it is in the
> > CVS configuration file. Like I said, and another poster agreed with,
> > using the user's .subversion/config file for doing this is just not
> > viable.
>
> If it were me, I'd supply the users with a .subversion/config file
> that they should use, and then use a hook script to make certain that
> they do indeed use it (by checking that the properties have been set
> correctly).
See above.
> > I want to use the KISS principle on the whole process. The more
> > complex it is, the more prone it is to error.
>
> Agreed, but I personally think modifying the repository (even in a
> post-commit hook script) is more complex and error prone than a hook
> script that rejects invalid commits.
The more we leave it to the human, the more prone it is as well. I've
had to manually repair CVS files because of user goofs. I'd rather just
do the work with hook scripts. It can't be that hard to look at the
file being commited and see if it matches the same criteria that we have
been using with CVS and if it doesn't match the criteria, to apply the
svn:keywords property to it.
> Anyway, I wish I could tell you that my book would help solve all of
> your problems with this issue. Unfortunately, I'm not sure it has a
> lot in it that will help you out.
If the book provides enough examples to ultimately provide me with the
clues in which to build hook scripts to do what I want in the previous
paragraph, I'll be happy. Right now, I haven't a clue as to where to
even begin. Obviously I'd be doing testing against a repository that I
would ultimately end up burning.
MB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 26 00:35:11 2005