Re: Post Commit Code Formatting

On 6/22/05, Durfee, Bernard <Bernard.Durfee@suny.edu> wrote:
> > The problem is very simple: The pre-commit hook runs on the
> > server, but the code that needs munging sits in the working
> > directory on the client side.
> >
> > In order to do this type of munging, the conversation between
> > the server and client must be greatly enriched. Right now,
> > it's basically the client sending information for the
> > archive, and the server giving a resulting status. To have
> > the pre-commit hook modify the code, it would need to send
> > each mod back to the client. All of this for a feature of
> > rather dubious value.
>
> Where does the RCS keyword expansion take place?

I answered this in my earlier post: It all happens on the client side.
The server doesn't expand the code at all. Try this:

$ svnadmin create test_repos
$ svn co file://$PWD/test_repos test
$ cd test
$ cat > testme <<!EOF
This will expand as $Id$
!EOF
$ svn setprop svn:keywords Id testme
$ svn commit

If you look at the "testme" file, you'll see that $Id$ has been
expanded on your machine.

$ cat testme
This will expand as $Id: $Id: testme 2 2005-06-22 21:11:40Z qazwart $

However, if you look what is actually stored on the archive, you'll
see it isn't expanded:

$ svnlook cat -r1 ../test_repos testme
This will expand as $Id$

> > Now, you could create a post-commit hook that immediately
> > checks out the files that were just committed, mucks them up,
> > then recommits them back to the archive. All you need is a
> > way for the post-commit hook to know that it shouldn't run a
> > second time around. A lot of people do something similar
> > with "svn export" to automatically update a directory on a server.
> >
> > Of course, your developer will now be sitting there with an
> > out-of-date working copy, and will have to remember to do an
> > "svn update" to put the changes into their working copy.
> > Plus, they'll have to wait until they're sure whatever
> > process you're running is finished and has completed its
> > commit operation.
>
> Right, not the solution I am looking for.

So, what are you looking for? As I pointed out, the hook runs on the
server, and not the client, but the files you want to manipulate are
sitting on the client side. This is really the biggest reason for
Subversion not doing any file modifications during the commit: It
can't unless it is substantially rewritten. And, all for a feature
that most SCMs wouldn't want.

>
> > The pre-commit hook running on the server side is a big
> > disadvantage of using Subversion. But it is also a big
> > advantage too...
> >
> > I had been doing ClearCase administration for well over a
> > decade, and ClearCase has a similar feature to hooks called
> > "triggers". Unlike Subversion hooks, triggers run on the
> > client side which means you can do anything you want to the
> > file in a trigger before it is actually checked in. However,
> > because it runs on the client side, you now are responsible
> > to make sure each and every client is setup correctly.
> >
> > Imagine over 100 people on a project with each and everyone
> > on a differently configured client. You have to make sure
> > that every trigger you write will work with all the hundreds
> > of flavors of Unix and of course all of your PCs. Of course,
> > IT is helping you out by upgrading OS's, installing software,
> > or even giving people new computers, and forgetting to let
> > you know. I spent a good chunk of my time just making sure
> > PCs and workstations were configured correctly.
> >
> > With Subversion, I don't care if the developer uses a PC, a
> > Linux box, Unix server, a Mac, or even an Etch-A-Sketch. As
> > long as they can get a Subversion client for whatever they
> > use, they can do their development work. My hooks merely make
> > sure that the code is in the right format before it is
> > committed, and that all of the needed properties are
> > correctly set. If something is wrong, I reject the commit and
> > give the user a nice explanation what went wrong. My hook
> > only has to run on a single system and I no longer have to
> > worry about the client's configuration.
>
> How does it make sure the code is in the proper format?

You enforce the standards by rejecting any code that isn't in
compliance of your standards. How the code gets into compliance is up
to the user. They could write a simple shell script that will run the
formatter, run the tests, and if everything is good, commit the code.
Maybe someone will write an emacs macro to do that. Maybe the
developers could find an IDE that does the task for them. They might
simply decide to change their coding style to fit the standards
required in the project.

Submitting code that is compliance of your standards is the user's
resposibility.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org