Post Commit Code Formatting

["Durfee, Bernard" <Be...@suny.edu>]

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

Re: Post Commit Code Formatting

[kf...@collab.net]

"Durfee, Bernard" <Be...@suny.edu> writes:
> 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.

The resistance is due to the difficulty of implementing it.  I don't
know why you think it's "simple".  I notice you haven't submitted a
patch for it, or even a design proposal that addresses all the
technical issues.

You can continue to be "amazed" by the resistance, or you can try to
solve the problem yourself, and see how simple it is or isn't.

> 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.

Our opposition to the feature is not on philosophical grounds, it's on
the technical grounds that not worth the trouble to implement.  If you
say that's wrong, then you're saying it *is* worth the trouble to
implement.  So, implement it!

This is how things get done around here.

Best,
-Karl


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

RE: Post Commit Code Formatting

[Casper Hornstrup <ch...@csh-consult.dk>]

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Rainer Müller
> Sent: 22. juni 2005 19:56
> To: users@subversion.tigris.org
> Subject: Re: Post Commit Code Formatting
> 
> Durfee, Bernard 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.
> 
> If you could format it you could do anything with it. And what would
> happen if it breaks the file so you can't build anymore? Remember, you
> would get _untested_ source code in the repository which is not a good idea.
> 

Your formatter has a bug then, so remove the bug in the formatter.

Casper



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

Re: Post Commit Code Formatting

[Rainer Müller <mu...@gmx.de>]

Durfee, Bernard 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.

If you could format it you could do anything with it. And what would
happen if it breaks the file so you can't build anymore? Remember, you
would get _untested_ source code in the repository which is not a good idea.

> 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?

Reformatting the source code is something bigger than keyword expansion,
because keyword expansion is "safe". It won't break the file.

Rainer


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

Re: Post Commit Code Formatting

[Greg Thomas <th...@omc.bt.co.uk>]

On Wed, 22 Jun 2005 16:53:52 -0400, David Weintraub
<qa...@gmail.com> wrote:

>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.

Hmm, I can see how versioning on a etch-a-sketch could be really
useful. "Damn, I've just accidentally shaken it. Never mind, I'll
revert to the previous version ..." :-)

Greg
-- 
This post represents the views of the author and does
not necessarily accurately represent the views of BT.

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

Re: Post Commit Code Formatting

[David Weintraub <qa...@gmail.com>]

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 <Be...@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