On May 25, 2005, at 5:32 PM, Michael L Brown wrote:
> 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.
The examples will help you write a hook script, but there's nothing
in there that will help you much with the specific parts of the hook
script that apply towards trying to modify the repository during the
commit (which would have to be a hack, given the way Subversion is
designed).
>
>
>> 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?
On the client
> 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, unfortunately that is not possible. Hook scripts cannot edit a
transaction that has been received from the client (well technically
they can, but you're asking for trouble if you try it). The only
remotely safe way to make a modification to the repository on the
server side, in response to a commit, is to perform the commit and
then perform a second commit in the post-commit hook. Subversion has
no way to automatically communicate that second commit back to the
client though. That means that the client will end up one revision
out of date, and will know nothing about the changes made by the
server until the next 'svn update'.
>
> 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.
I wish I had better news for you, but I just don't think you're going
to have any luck getting anything like this to work with the current
SVN architecture. I think there are good arguments for allowing a
hook script to modify the data being committed, but it's going to
take a major modification to the way the subversion repository works
(at least that's my understanding).
One option for you would be to write your own client (or better yet,
modify the existing client) that provided a custom add that would
examine the files to determine their type using a more sophisticated
algorithm than the current client does.
>
>
>>> 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.
Given the current SVN architecture, I still think this is your best
option (assuming you can find a way around the file type matching
problems you described 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.
It wouldn't be hard if SVN had a way to do what you describe.
>
>
>> 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.
One thing that I do discuss at length in my book is how to integrate
SVN into your development process in ways that work with proper SVN
methodologies. You might find it helpful in giving you a better
understanding of the way SVN is designed and why certain things are
hard/easy.
-Bill
>
> MB
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 28 01:23:03 2005