> 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.
*Someone* has to care, and since a post-commit RCS key expansion is
still plain text when you send it out to a third party, it is just
another piece of unreliable information that can be (maliciously or
otherwise) edited, deleted, etc. I wouldn't bring it up if I haven't had
it happen over and over again to me. Relying on RCS keyword expansion
insinuates that you are looking at code that is not in a repository,
which means it is not, physically, necessarily what's in your repo (or
depot, or vob, or whatever your tool uses.) Maybe it's good to see when
you're reviewing code or what have you, but I'd never rely on an
editible piece of text to tell me what code I have.
> 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.
In the case of a mag or a book, sure, but you *know* someone is editing
your stuff, which is fine. But I still doubt Newsweek would accept an
article written on a cocktail napkin or two. There are still certain
protocols you'd have to follow for the particular publisher or
publication. Have you ever had to write a dissertation or article for a
scientific journal? (I haven't, but I know people that have.) There are
very specific parameters you must follow for the paper to even be
accepted into the system, including font, margins, etc. *They* don't do
that for you, *you* do 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!
My point exactly!
I'm not against giving subversion abilities that would allow this kind
of thing to be implemented, but I just think that for the purpose of
what Subversion does, this is too specific, and does not have enough
support in the community (CM community as a whole) to bother with.
Source control has been around for decades and this kind of thing has
been discussed forever, but still nobody has done it. Advertising
Subversion as a source control tool that modifies code after it is
submitted would greatly tarnish its reputation, in my opinion. (note
from earlier posts that Subversion does not store RCS keywords in an
expanded state. It translates them, client side, on the fly, which is
good.)
-Matt
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 23 18:54:31 2005