CR->LF conversion with commit hooks?

[Hamilton Link <he...@sandia.gov>]

I have this vague impression that the various svn repository hooks can 
do wonderous, magical things. Can they alter files being committed to 
the repository such that the client figures out this is happening and 
effectively auto-updates to capture changes made at commit time?

At one point I think I saw someone asking if the commit hooks could 
auto-format C code; I don't know what the verdict on that was. In my 
case, it would be to enforce that code files are considered text files, 
convert CRs to LFs, do not have svn:executable as a property, and have 
svn:mime-type set to text/plain.

Why is this important to me? Well, certain Mac OS X applications 
default to using CR as an end-of-line marker, but most of the unix 
underpinnings in Mac OS X can't really cope, and I _really_ don't want 
files of both flavors floating around the repository. I'd like to stamp 
out the CR files, but I'd rather people not have to constantly remember 
to run little conversion utilities before they add or commit files into 
the repository, and I'd *really* like commits to not be rejected due to 
easily-detected, easily-fixed trivium, or it will be a major barrier to 
use.

thanks,
h



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: CR->LF conversion with commit hooks?

[Simon Large <sl...@blazepoint.co.uk>]

"Hamilton Link" wrote
> Why is this important to me? Well, certain Mac OS X applications
> default to using CR as an end-of-line marker, but most of the unix
> underpinnings in Mac OS X can't really cope, and I _really_ don't want
> files of both flavors floating around the repository. I'd like to stamp
> out the CR files, but I'd rather people not have to constantly remember
> to run little conversion utilities before they add or commit files into
> the repository, and I'd *really* like commits to not be rejected due to
> easily-detected, easily-fixed trivium, or it will be a major barrier to
> use.

You are aware of the svn:eol-style property which can sort out line endings
for you? eol-style native will store text files with plain LF endings and
update clients in their preferred native format.

Simon




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: CR->LF conversion with commit hooks?

[kf...@collab.net]

"Hamilton Link" <he...@sandia.gov> writes:
> I have this vague impression that the various svn repository hooks can
> do wonderous, magical things. Can they alter files being committed to
> the repository such that the client figures out this is happening and
> effectively auto-updates to capture changes made at commit time?

No, they can't.  They can alter the files being committed, but there
is no way to tell the client about this -- therefore it is imperative
that you never, ever alter the files being committed on the server
side :-).

> At one point I think I saw someone asking if the commit hooks could
> auto-format C code; I don't know what the verdict on that was. In my
> case, it would be to enforce that code files are considered text
> files, convert CRs to LFs, do not have svn:executable as a property,
> and have svn:mime-type set to text/plain.

You shouldn't do this.  But what you can do is have a hook that
rejects improperly formatted C code, so the commit fails, and the
committer fixes the problem.  Or it can reject the commit for some
other reason, like the ones you give above.

Rejecting a commit via pre-commit-hook is always okay.  Altering a
commit is not.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org