On Jun 22, 2005, at 7:25 PM, Mark Phippard wrote:
>
> The reason's for this are *entirely* technical. If you alter the
> content
> of the file before it is committed, the WC of the user that
> committed the
> file will not contain the same changes, but the WC will think it is
> up to
> date. An svn up would not bring down any changes, and subsequent
> commits
> to the file would likely fail because the delta's would not line up
> (I am
> only speculating on this part).
>
> To allow the hook to alter the transaction would require significantly
> redesigning the commit process so that the changes could be sent
> back down
> from the server to the client. It would be a hefty amount of work
> for a
> feature that is dubious at best, and can be implemented in much saner
> ways.
>
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.
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 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 03:00:46 2005