> Exactly. Commit is currently a one-way communication process. To
> make it two-way will take quite a bit of redesign and coding.
> That's the 'technical' hurdle. The reason nobody's taken up this
hurdle is
> because there's a general feeling among developers that this feature
> isn't exactly a best practice to begin with.
I see.
> That's why the most common response is: "don't have the server
> reformat the code, just have it validate the code and reject the
> commit if the user failed to run the formatter themselves."
>
> In other words, the problem of "make all code nicely formatted" is
> already solvable as a social problem via the pre-commit hook. A lot
> of folks seem to interpret this as a philosophical war, but it's
> not. If we were writing svn from scratch, we might very well design
> commit to be 'two-way' from the start, knowing what we know
> now. But at this point, few developers think it's worth the bother.
Lots of
> work for little benefit.
Well put. Although the level of benefit is dependant on one's own
beliefs regarding best practices and distribution of responsibilities.
Bernie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 17:01:13 2005