G'day Alan,
You still have the problem that the repository will contain checked in
code that has not been eyeballed / compiled / tested by a person. All
you've done is shifted the place that those changes occur from pre-
commit to post-commit, which in many regards is even worse, since
you'll invariably end up with two commits for every commit a developer
performs (in my experience even the most conscientious of developers
can't adhere to 100% of whatever formatting rules you've defined;
through no fault of their own I might add - humans just aren't good
at paying that much attention to detail).
FWIW I think a combination of having an easy-to-use pretty printing
target in your build scripts, plus a pre-commit hook that aborts the
checkin of non-pretty-printed code probably makes the most sense. It
gives the developers no choice but to pretty print their stuff before
they check it in, while also giving them no excuses about how "hard"
it is to pretty print their code.
Cheers,
Peter
----------------------------------------------------------------------
Peter Monks http://www.sydneyclimbing.com/
pmonks_at_sydneyclimbing.com http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------
> -----Original Message-----
> From: Alan Jay Weiner [mailto:alan@ajw.com]
> Sent: Thursday, 19 August 2004 8:46am
> To: users@subversion.tigris.org
> Cc: Zeus Gómez Marmolejo
> Subject: Re: Automatic pretty-print
>
>
> There's been lots of comments about why pretty-printing *at*
> commit time is a
> bad idea, including that it isn't permitted at all...
>
>
> Why not allow the commit to occur, and the post-commit hook
> triggers a script
> which:
> sets a flag indicating pretty-print is occurring
> (creates a file named "pretty_print_active" or such...)
> updates a local working copy
> pretty-prints the files
> (just the changed ones if you want to detect that)
> commits the now-pretty-printed files
> (with a log message that they've been pretty-printed)
> deletes the flag
>
> The pre-commit hook checks for the "pretty_print_active" flag
> and fails if it's
> there.
>
> That way the developer commits their changes exactly as
> they've tested them, and
> the repository is generally in pretty-printed form, and it's
> all automatic.
>
> There's a window where the repo *isn't* pretty-printed of
> course, and there's
> the issue of what if the pretty-print script dies leaving the
> "active" flag set,
> but it sounds workable to me.
>
> - Al -
>
>
> -- original message --
>
> >Hi all,
> >
> >I'm using subversion since no much time and I think it's
> great, much more than
> >cvs.
> >
> >I would like to ask one question. I want all the source .c
> files in my
> >repository to be well pretty-printed, all conforming a
> common C programming
> >style. But the problem is that the programmers don't do the
> job well, they
> >forget to follow the rules and so...
> >
> >The ideal think could be at the pre-commit hook execute the
> pretty printer for
> >all the .c source files so that in the repository the files
> all are well
> >stored. Also it would be desirable to check C syntax so all
> files that are in
> >the repository complile all. But I've seen the comments on
> the pre-commit
> >template hook and explicitly reports that the script must
> not change the
> >transaction. So is there a way to transform (pretty-print)
> the source files
> >before committing them?
> >
> >If this is not possible, it will be very nice to add it as a
> new feature :D,
> >
> >Regards,
> >
> >Zeus.
> >
> >----- Terminar mensaje reenviado -----
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
> --
> -- Alan Weiner -- alan_at_ajw.com -- http://www.ajw.com
> Palm OS Certified Developer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 19 19:24:40 2004