> At the risk of p'ing off users of this list,
> the original post did seem a little demanding, which is not
> the way to approach open source projects. I've seen this
> kind of thing before and I wonder if it may be a side-effect
> of folks from the consumer world coming over to the dark
> side. Or is it the light side? I don't even know any more.
It's all the same, just not as expensive.
> So chalk it up to whatever, but on a purely philosophical
> note, there is a reason that this kind of thing has been
> discussed in the past (for other tools) and shot down.
> Namely, it's a terrible idea. Altering code, especially
> unbeknownst to the author, once it has been submitted is not
> the MO of any source control tool I've ever seen, and I've
> used a lot of them. It doesn't matter that it's 'just
> formatting'. The job of a good source control tool is to keep
> impeccable records about the code that has been checked in,
> not a slightly altered version of it. I've worked in some
> regulated industries and if they (SEC, FDA) audit you (and
> the FDA does regularly) and found that you altered code using
> a script once it was checked in, you'd be shut down. Doesn't
> matter what or why.
How does RCS keyword expansion fit into this? Does that not modify the
contents of the user's committed file? In fact there are a myriad of
tools that perform pre-processing of source before compilation. In fact
compilation itself can change the behavior of source code. In addition,
source code generally relies on external libraries that can be changed
and modified even as far down the road as runtime. Source code
formatting should be the least of the developers worries when it comes
to the intended behavior of their source code being reflected in the
actual behavior of the application. In fact they shouldn't have to worry
about it at all, their tools should take care of it for them.
> If your engineers are not coding against your standards, they
> need to be taught to do so. I would urge you not to alter
> their code behind their backs. If they aren't *writing* in a
> certain style, then they won't be able to *read* it later. A
> better idea might be to have a mechanism to check the coding
> style and refuse the checkin if it is not up to snuff.
I'm not convinced. There really is no reason that code formatting
shouldn't be integrated into a repository. It still seems to me that it
would be very convenient to check-out a piece of code, have it displayed
in a format it to my liking, modify it, then check it back it without
thinking of the formatting. If there is a conflict, the diff will be
displayed post-format, which will factor out all insignificant
differences and show only logic differences. This is simply an
enhancement to a tool, allowing developers to work in a style they feel
comfortable in while still maintaining a consistent easily diff'ed style
in the repository. Formatting factors out insignificant changes, so
revision 1.1 is truly different than revision 1.2.
Bernie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 22 22:58:15 2005