RE: Re: Setting eol-style property on post commit hook

H Farhan,

Have you considered using the auto-prop set feature in subversion on the
client side.
This will ensure that the required properties are set when a file is
"added".

There are is no work-around for existing files.

Thanks
Lakshman

-----Original Message-----
From: mfs [mailto:farhan.sarwar_at_gmail.com]
Sent: Tuesday, 25 March 2008 5:32 PM
To: users_at_subversion.tigris.org
Subject: Re: Setting eol-style property on post commit hook

Thanks for the quick followup Ryan.
 
A couple of follow up questions below...
- Hide quoted text -
 
On Mon, Mar 24, 2008 at 4:58 PM, Ryan Schmidt
<subversion-2008a_at_ryandesign.com> wrote:
> On Mar 24, 2008, at 18:33, mfs wrote:
>
> > So basically i want to set an eol-style property to native for all
> > my text based files. I will be enforcing this by making the
> > developers/ committers enable the property "enable-auto-props" and
> > accordingly set the file extensions on which the property is applied

> > in their subversion/ config file.
> >
> > BUT at the same time for users who mistakenly (or carelessly) dont
> > set the property, i would want to have a script executed on
> > post-commit hook on the subversion server.
> >
> > Now i have following questions/concern
> >
> > 1) Is it a good idea to set the property using a script invoked on a

> > post-commit hook ? What implications can it have. In certain threads

> > people have suggested to rather have a strategy where the commits
> > are rejected if the property is not already set. Why is such an
> > approach suggested over the first one ?
>
> I would recommend instead that you reject unsatisfactory commits and
> make the developer do it right in the first place. After a few
> mistakes, they'll learn to do it right.
 
I understand, and may be thats the approach i would eventually opt, just
clarifying the concept completely before choosing this option.
 
>
> The problems with doing it in a post-commit hook are that you need to
> keep track of a working copy on the server, and you create an
> additional revision just for the property changes, and the user's
> working copy is thus immediately out of date and they have to
> immediately do an "svn update" after each "svn commit" where they have

> forgotten properties. And if you can't get them to remember to set
> properties, why would they remember to do an update?
 
User requiring an svn update makes sense, but wondering if that the same
reason you mentioned that one would need to keep track of the working
copy on the server..?
 
>
> > 2) Now, If it is ok to have such script, would the script require
> > doing an svn update and (after svn propset to eol-style) a commit
> > again ?,
>
> Yes, that's correct.
>
> > cant we
> > just update the property on the actual files without the need to
> > synchronizing them and doing another commit
>
> No, that's not possible. You cannot modify the transaction in
progress.
>
> > (since that i believe would
> > introduce another revision just for setting the property),
>
> Yes, it would create a new revision just for the property setting.
>
> > given the hook be
> > running on the same machine..
>
> The hook is running on the server. The user's working copy is on the
> client. The hook script would have to have its own working copy on the

> server for this purpose.
>
>
 
Make sense...Anyways...So even for setting this property for the first
time (on all text based files) we have to do an svn-update (set
property) and do svn-commit on each file (or via a script though)
?..Doesnt the subVersion server module have any tool which does it for
you behind the scene ?, even though i understand a new revision would
still be created...
 
If not, does any of the subversion's client interface provide such a
utility, i know its not a big deal, but still trying to know the best
and the quickest possible way to achieve the task.
 
Thanks again

--
View this message in context:
http://www.nabble.com/Setting-eol-style-property-on-post-commit-hook-tp1
6264145p16269032.html
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email. 
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure 
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org