> I don't use RCS keyword expansion for this very reason ;).
And if implemented, you probably wouldn't use automatic code formatting
either.
> Processing code before compiling and after checkin are two
> completely different things. SCM involves tracking more than
> source code, as you allude to above. Also, you say their
> tools should take care of it for them, and I agree. Developer
> tools being their IDE or editors. Source control being an SCM
> tool. I'm paid to track and build code, not alter it once
> it's in my hands, by using a tool or otherwise. I can go on
> and on about how the information in any RCS keyword is
> contained in the metadata of any file in the source control
> database anyway, so it's inherently useless. If you are
> sending your code out to a third party, you damn well better
> know what it is when you send it and where it came from, lest
> your third party edit your RCS keywords
> (expanded) out so they can get a decent diff.
Sounds like a mighty tight ship you run. I tend to lean more toward
allowing choice and flexibility through technology than rigidity through
mandates. By using RCS keyword expansion to include the revisioning
information in the source code itself, developers do not have to damn
well remember what it is their sending and where it came from. Their
tools assist them and let them worry about more mundane things, like
doing their job.
> I still respectfully disagree. If I'm writing code or a
> novel, I don't want someone editing it without my knowledge.
No problem, don't use the feature. If I am running a magazine with
dozens of contributors, I certainly want someone to edit the incoming
content so that the magazine has a consistent look and feel from page to
page. I don't want to rely on simply setting some formatting rules and
trying to enforce those rules on those dozens of contributors, most of
which probably are better off spending their time creating content than
trying to make sure it is formatted to adhere to a set of common
standards.
> Here's another example in a different context that I come
> across practically every day: Why Johhny Can't Write -
> Because he doesn't have to know how to. Johnny is in his
> early 20's and is a college graduate. Johnny comes to work at
> Corporation X and has to give a presentation, complete with
> marker board. His notes on the board look like someone
> illiterate wrote them. He doesn't speak in a very articulate
> way, either. Why? Johnny has been reared on the
> auto-correcting word processor. His resume is impeccable, his
> e-mails read like Updike, but try to engage him in a hall way
> conversation and you wonder how Johnny can feed himself.
> That's a little bit of an exaggeration, but if you have an
> opportunity to talk to 'kids these days' you'll find a good
> chunk of them can't put together a complete sentence to save
> their lives. Mainly because they've never had to, the word
> processor does it for them. So, is this a good scenario? Is
> it good to let Johnny programmer think he's writing the best
> code in the world? Perfectly formatted to the Corporation's
> coding standards? Even though he's not? What happens when
> Johnny's code is reviewed and someone has to ask him about
> it? He might not even recognize it. And God forbid Johnny is
> called upon to review someone else's code. He's not even
> speaking the language. Better for Johnny to know the language
> than to have someone secretly interpreting his lousy code.
> The code will bite back one day, I guarantee it.
Wow, I didn't realize that automatic code formatting would lead to the
eventual demise of the world as we know it. Good thing no one has
implemented it!
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 16:38:06 2005