[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Post Commit Code Formatting

From: Durfee, Bernard <Bernard.Durfee_at_suny.edu>
Date: 2005-06-22 20:15:14 CEST

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

And? Isn't it up to the maintainer of the repository to make sure that
the script(s) run against the files are understood? So the lack of
CVS/Subversion support for such a hook is saving users of CVS/Subversion
from themselves? Is all source code that goes into a repository always

> > Whether or not automatic formatting of committed files is
appropriate is a purely philosophical debate. In my mind it is simply an
> > 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.

Expansion is only as safe as the developer who checks in the code right?
Isn't it possible for a keyword to be expanded to contain a quote,
double quote, double dash etc. Doesn't that mean when a keyword is
expanded it may break the file by placing bad characters in a bad place?
Is keyword expansion really smart enough to always avoid every problem
that it may cause? Or is it up to the developers and repository
maintainers to make sure that keyword expansion does not alter the files
they are committing in such a way as to make them 'broken'?

Again, it seems like it would very simple for CVS/Subversion to supply a
'hook' for people to run scripts to modify incoming files and transmit
those modifications back to the client, just as both of those systems
already do with keyword expansion.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 22 20:17:16 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.