[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-23 16:37:41 CEST

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

So the SVN client is doing the expansion.
> > 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.

So the client is only sending deltas to the server. For the post commit
solution to work, a checkout needs to be done to build the file from the
deltas that were committed to the server, that file could be formatted
and then committed. I can see now how it is technically challenging to
implement this on the server side, at least in a reasonable way.

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

I agree that it is currently the user's responsibility, I was suggesting
that it would be an improvement to the system if that responsibility
could be shifted off of the individual developers.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 16:53:30 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.