Re: Post Commit Code Formatting

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.

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.

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.

If the user wants to, they could develop their own "commit script"
that would do whatever munging is needed, test the newly munged code,
then commit it back to the source archive.

On 6/22/05, Durfee, Bernard <Bernard.Durfee@suny.edu> wrote:
> I've seen this topic come and go over the years in CVS and now in
> Subversion. It amazes me the amount of resistance put forth by the
> maintainers of both of these projects. It's just a feature. A useful
> feature that can be used or ignored. Providing a simple hook somewhere
> in the commit path to run a script to format the incoming file before
> the commit and to transmit the changes back to the client.
>
> Whether or not automatic formatting of committed files is appropriate is
> a purely philosophical debate. In my mind it is simply an extension of
> the already convenient RCS keyword expansion provided by both CVS and
> Subversion. Imagine, if you will, a world in which RCS keyword expansion
> didn't exist. Would you ask developers to make sure to update the
> revision number and commit time in each file before they committed it?
> Why force them to remember to run the code through a formatter before
> they commit it?
>
> Please CVS and Subversion, give the world a way to easily and
> appropriately integrate code formatters.
>
> Bernard Durfee
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

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