kfogel@collab.net writes:
> "Garrick Olson" <Garrick.Olson@Aceva.com> writes:
> > This issue of not being able to modify things on the server side is
> > causing tremendous pain in my environment as well. I strongly
> > encourage the svn
> >
> > developers to consider some viable approach to deal with this issue. In
> > case
> > you are interested, my goals are:
>
> 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.
I've considered in the past how such a thing might be implemented.
Remember, making an auxiliary commit from within the post-commit hook
will itself trigger, yes, another post-commit hook.
The easiest thing I could think of was to write the hook such that it
only did the reformatting for revisions that lacked a special
'cmpilato:reformatted' revision property. And of course, the last
thing the reformatter would do before making the auxiliary commit
would be to set a 'cmpilato:reformatted' txn prop. No infinite
recursion.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 05:35:00 2004