begin quoting David Brown as of Sat, Jul 19, 2008 at 10:03:55AM -0700: > On Sat, Jul 19, 2008 at 12:54:15PM -0400, [EMAIL PROTECTED] wrote: > >On Sat, Jul 19, 2008 at 08:37:17AM -0700, Lan Barnes wrote: > >>keyword expansion is just plain evil. Anything that mungs source is evil. > > > >Really? I've derived a lot of happiness from it. It Just Works for me. > > Really. They are probably the single most obnoxious attribute of our use > of P4 at work, especially given P4's blurring of branch and directory > names. Just branching a file causes the version stamp to change, making > merges or even just diffs obnoxious.
Well, branching *is* a change to the source, in a sense. You're moving its location. That *should* cause a revision bump. (I suppose if you consider the location of source files to be irrelevent metadata, then this line of thinking would make zero sense whatsoever.) > I'm beginning to feel that _any_ process that involves putting history data > somewhere in the source tree is just an indicator of a missing feature from > a revision control system. Keyword expansion just indicates that the > system either doesn't keep track of file versions very well, or isn't > distributed. If the revision control system is distributed, and everyone > who has the source, has the revision information, then they aren't needed. Um... I disagree. Sorta. If you're working with interpreted languages (as in having no compilation), yah, because everyone who has the program has the source, and everyone who has the source could have the revision information. But when you compile a program, what you ship isn't source, and thus there's no way to identify a buggy installation with the appropriate source tree snapshot. There's decent two ways of fixing that: embed revision information in the file, or impose a more rigorous release process. > Another is a "ChangeLog" file. The need to write history information into > a file suggests that the history in the revision control system either > isn't very good, or isn't accessible. Mostly changelogs are for accumulating the change information for distribution, aren't they? > The problem is that the ChangeLog information is detached from the actual > changes. If I've got a distributed copy of the history, along with the > change descriptions, I can see the real diffs, and look at the real old > versions. [out of order] > BTW, something like "NEWS" which summarizes a bunch of changes in a release > is still useful. Isn't that what a Changelog file is *for*? Am I misunderstand the reasons folks use a changelog? > Even finding commented-out code suggests that the programmer thought it > would be too hard to find or retrieve that code later from the revision > control system. I've yet to see a revision system that is good enough to beat the utility of commenting out pieces of code. Any system that could accomplish the same thing would be too complicated to use by folks who want to code instead of playing with their VCS. Now, commenting out code and leaving it commented out for long periods of time... yah. That's not trusting the VCS. -- Making more than one change at a time. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
