RE: Post Commit Code Formatting

I think this comes down to a "how much bang for your buck" type discussion.
To implement server-side code reformatting, major changes would need to be
made to the Subversion protocol exchange. That entails changes in all of
the clients, interoperability testing, and a requirement for users to
upgrade their client. With the recent addition of locks to svn, users don't
have to upgrade if they don't want to use locks. But if a svn admin wanted
to re-format code on the server side, then they would have to disallow older
clients that don't understand the new protocol exchange that is capable of
sending changes back to the client.

So, a lot of work for a feature that some consider to be against best
practices.

I think it's a mistake to frame this as a "the svn devs won't flick the
switch to make this work" situation. It's a major undertaking, and would
take some time to develop I would think.

That being said, the roadmap does have "Log message templates" and
"Repository-defined autoprops" as medium-term goals. I'm guessing that
those would also require some changes to the protocol, though similar in
scope to locking. Perhaps when those tasks are taken on, some hard
technical details about what the technical challenges server-side
reformatting entails will come to light and people can get down to designing
those changes or deciding that it's not worth it.

I would like to chime in on the fact that there are viable procedural
solutions to this problem which can be reinforced by subversion today. As a
developer, I will modify my personal behaviour to avoid daily annoyances.
If those annoyances are from svn telling me that my code doesn't fit a
standard, I'll quickly learn to make my code fit, even if the solution at
first is just a shell script wrapper around the svn command.

Take a completely non-technical issue: my company has a nominal business
casual dress code. If I come into work one day wearing bermuda shorts,
they'll probably ask me to go home and change into something more
appropriate, which I will do. This will cost me time and money. The next
day, the chances of me completely forgetting what happened the day before
and wearing bermuda shorts again is lower (but perhaps not entirely gone).
Over time, I will learn. If I wasn't capable of doing so, I have probably
chosen the wrong career path.

Regards

-----Original Message-----
From: Jake Robb [mailto:jakerobb@mac.com]
Sent: Wednesday, June 22, 2005 5:08 PM
To: 'Janulewicz, Matthew'; users@subversion.tigris.org
Subject: RE: Post Commit Code Formatting

Second, while I understand the reasons given, I'm not sure I agree. Is it
Subversion's job to prevent anyone from engaging in activities which are
forbidden in select industries? Has the Subversion team, at some point,
decided that it would be wrong to provide a means to engage in activities
which the industry at large does not acknowledge as "best practice"?

It seems to me that the Subversion developers have decided to lock a door
for reasons which are primarily non-technical, and it seems to me that those
whose industries do not prohibit automatic code alteration should be allowed
to use that door if they choose to do so.

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.7.11/26 - Release Date: 6/22/2005
 
-- 
----------------------------------------------------------------------------
This electronic message contains information from Primus Telecommunications
Canada Inc. ("PRIMUS") , which may be legally privileged and confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or e-mail (to the number or address above)
immediately. Any views, opinions or advice expressed in this electronic
message are not necessarily the views, opinions or advice of PRIMUS.
It is the responsibility of the recipient to ensure that
any attachments are virus free and PRIMUS bears no responsibility
for any loss or damage arising in any way from the use
thereof.The term "PRIMUS" includes its affiliates.
----------------------------------------------------------------------------
Pour la version en français de ce message, veuillez voir
 http://www.primustel.ca/fr/legal/cs.htm
----------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org