You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jean-Luc Wasmer <jl...@wasmer.ca> on 2003/05/09 13:13:25 UTC
Beautify code thru a hook
Hi,
I checked the SVN book (specially the section about the hooks) but I can't
find how to do this.
How can I filter committed files thru a code beautifier (like astyle)?
Thanks,
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Jean-Luc Wasmer <jl...@wasmer.ca>.
> > > How can I send back the message "File doesn't comply to rule XYZ" to
the
> > > client?
> >
> > Make your pre-commit hook return exit code 1. I don't remember if you
> > can throw a specific error-message back, though.
>
> Based on behaviour (and not on the code), both the svn command line
> client, and TortoiseSVN both display anything printed to STDOUT by
> the post-commit hook.
>
> We use this here to run Java code through "checkstyle" before allowing
> commits. Providing a quick "make check" in the project Makefile
> means that people don't even complain about it too much.
>
Would you mind sharing your hook?
Thx,
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Sat, 2003-05-10 at 02:05, Ben Collins-Sussman wrote:
> "Jean-Luc Wasmer" <jl...@wasmer.ca> writes:
> > How can I send back the message "File doesn't comply to rule XYZ" to the
> > client?
>
> Make your pre-commit hook return exit code 1. I don't remember if you
> can throw a specific error-message back, though.
Based on behaviour (and not on the code), both the svn command line
client, and TortoiseSVN both display anything printed to STDOUT by
the post-commit hook.
We use this here to run Java code through "checkstyle" before allowing
commits. Providing a quick "make check" in the project Makefile
means that people don't even complain about it too much.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Ben Collins-Sussman <su...@collab.net>.
"Jean-Luc Wasmer" <jl...@wasmer.ca> writes:
> ----- Original Message -----
> From: "Garrett Rooney" <ro...@electricjellyfish.net>
>
> > >How can I filter committed files thru a code beautifier (like astyle)?
> [...]
> > what you could do is have a pre-commit hook that verifies that the code
> > being checked in conforms to the style guidelines, and if it doesn't
> > refuse to proceed with the commit. i don't know of anyone who's done
> > this, but it shouldn't be that hard.
>
> How can I send back the message "File doesn't comply to rule XYZ" to the
> client?
Make your pre-commit hook return exit code 1. I don't remember if you
can throw a specific error-message back, though.
> What about doing this in the post-commit hook. There wouldn't be
> any pbms with the client since the revision number would be
> incremented.
A post-commit hook would have to use svn_fs.h directly. You'll need
to be *very* careful that you don't accidentally trigger the
post-commit hook again, putting you into an infinite loop.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Jean-Luc Wasmer <jl...@wasmer.ca>.
----- Original Message -----
From: "Garrett Rooney" <ro...@electricjellyfish.net>
> >How can I filter committed files thru a code beautifier (like astyle)?
[...]
> what you could do is have a pre-commit hook that verifies that the code
> being checked in conforms to the style guidelines, and if it doesn't
> refuse to proceed with the commit. i don't know of anyone who's done
> this, but it shouldn't be that hard.
How can I send back the message "File doesn't comply to rule XYZ" to the
client?
----- Original Message -----
From: "Ben Collins-Sussman" <su...@collab.net>
> "Jean-Luc Wasmer" <jl...@wasmer.ca> writes:
>
> > How can I filter committed files thru a code beautifier (like astyle)?
>
> I'm going to pretend for a moment that this idea doesn't make me
> cringe. :-)
Be careful... I might be subverting you with a _very bad_ idea :-)
----- Original Message -----
From: <pw...@mdtsoft.com>
[...]
> I have been thinking about this; my current design is to have a thing that
> will be kicked off by cron,
What about doing this in the post-commit hook.
There wouldn't be any pbms with the client since the revision number would
be incremented.
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Jean-Luc Wasmer wrote:
>Hi,
>
>I checked the SVN book (specially the section about the hooks) but I can't
>find how to do this.
>
>How can I filter committed files thru a code beautifier (like astyle)?
>
right now you can't. if a pre-commit hook script alters the transaction
(meaning: changes the stuff that's being committed) there is no way to
propogate those changes back the the client doing the commit. you can
end up with the client and the server having different ideas of what the
new revision should contain, which breaks things. i think it's a
documented "don't do this" thing at this point. there's some debate
over whether this should be 'fixed', since the idea that doing 'svn
commit' can change the contents of your working copy is kind of scary.
what you could do is have a pre-commit hook that verifies that the code
being checked in conforms to the style guidelines, and if it doesn't
refuse to proceed with the commit. i don't know of anyone who's done
this, but it shouldn't be that hard.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by pw...@mdtsoft.com.
On 9 May, Ben Collins-Sussman wrote:
> "Jean-Luc Wasmer" <jl...@wasmer.ca> writes:
>
>> How can I filter committed files thru a code beautifier (like astyle)?
>
> I'm going to pretend for a moment that this idea doesn't make me
> cringe. :-)
>
> In theory, you'd write a pre-commit hook script which examines the
> pending commit transaction in the repository, and changes it. You'd
> probably have to use the svn_fs.h API to directly tweak the
> transaction, either via C or Python.
>
> But in practice, the svn client can't deal with this sort of thing.
> If the pre-commit hook changes file contents, the client currently has
> no way of learning about this. The server simply says "commit
> complete", and the client then goes on assuming that the files
> committed from the original working-copy directory are identical to
> the ones in the repository. This will cause detrimental things; 'svn
> up' and other functions will start to produce nasty checksum errors,
> and the original working-copy directory will slowly bitrot.
>
>
I have been thinking about this; my current design is to have a thing that
will be kicked off by cron, say about once per day, that will do the following
1) in its working directory (it will have one that will not be used by any
real user) do a "svn update" noting what files are chnaged. (I want
to do this with the perl bindings but I have not had time to work on
those for a while yet).
2) for each file that has changes process it (beautifier, check for proper
copyrights, whatever).
3) issue a "svn commit" with a comment that says that this has been a automatic
update.
The advantages of this are that all of the automatic changes will be look just
like they where done by a person. (abit one who works real late :-) )
The disadvantage is that for a while bad data is in in the store.
After this has been running for a while then put in a pre-commit hook that prevents
checkin if any of the checks fail (with a message to the user as to why the commit
was not accecpted and how to fix it).
--
It is MDT, Inc's policy to delete mail containing unsolicited file attachments.
Please be sure to contact the MDT staff member BEFORE sending an e-mail with
any file attachments; they will be able to arrange for the files to be received.
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please advise postmaster@mdtsoft.com
<ma...@mdtsoft.com>.
Philip W. Dalrymple III <pw...@mdtsoft.com>
MDT Software - The Change Management Company
+1 678 297 1001
Fax +1 678 297 1003
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Beautify code thru a hook
Posted by Ben Collins-Sussman <su...@collab.net>.
"Jean-Luc Wasmer" <jl...@wasmer.ca> writes:
> How can I filter committed files thru a code beautifier (like astyle)?
I'm going to pretend for a moment that this idea doesn't make me
cringe. :-)
In theory, you'd write a pre-commit hook script which examines the
pending commit transaction in the repository, and changes it. You'd
probably have to use the svn_fs.h API to directly tweak the
transaction, either via C or Python.
But in practice, the svn client can't deal with this sort of thing.
If the pre-commit hook changes file contents, the client currently has
no way of learning about this. The server simply says "commit
complete", and the client then goes on assuming that the files
committed from the original working-copy directory are identical to
the ones in the repository. This will cause detrimental things; 'svn
up' and other functions will start to produce nasty checksum errors,
and the original working-copy directory will slowly bitrot.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org