On Jun 22, 2009, at 09:31, David Weintraub wrote:
> As others have stated: You don't do this because of the consequences.
> In order to do this, you have to submit a SECOND commit which means
> that the person who just did the commit will find their working
> directory out of date.
> Plus, there is the possibility of your second commit firing off
> another pre-commit hook which might fire off another commit which
> might fire off a third pre-commit hook all the way through all seven
> circles of hell.
Assuming the script is written correctly that shouldn't happen, since
the purpose of the script would be to add an eol to the end of a file
that does not already end in an eol. But definitely while you're
writing the script you might not get it right the first time and
could easily find yourself with a script that causes an infinite loop
of commits. So it should definitely be developed on a temporary
throwaway repository and not on your production repository.
> What I do is require the svn:eol-style property on certain file types
> set to what is needed. For example, all *.sh, *.pl, Makefiles, and
> other Unix files that require a <LF> line ending only, or for example,
> all the special files that VisualStudio requires a <CR><LF> ending on.
> The property will make sure that the file is stored with the correct
> line ending in the repository, so your developers won't have to worry
> about it. You can also let your developers know how to configure
> autoproperties, so that when a new file is created, the correct
> property is setup when the developer runs "svn add".
> The autoproperties will keep your developers from getting frustrated
> with the whole line ending issue.
Yes, but the issue is not the eol-style of the entire file, but the
fact that he wants every text file to be guaranteed to end with an
eol, which is not something the svn:eol-style property has anything
to do with.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-22 17:18:41 CEST