I have considered several approaches, including this one. The main
disadvantages of this approach:
- There are race conditions and looping issues (as pointed out by Philip
Martin)
- The "commits" are no longer atomic, and thus may trigger two builds (I
am using a continuous integration process where builds are triggered by
commits)
- The commit emails are less readable ==> harder to review
- The first commit email from the developer may contain many "false"
differences (just formatting)
- The second commit email is just noise (of course this can be
avoided in the hook scripts)
--- Karl wrote:
Have you considered a solution that does the reformatting as a separate
commit? That way you get a "changeset" with exactly what the human
committed, and a separate one for what the automated formatter did to
it, which might in some ways be preferable anyway.
By this method, there would be no working copy synchronization problem.
People would just get the changes when they update, as usual.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 01:29:57 2004