From: Steve W. <sw...@pa...> - 2002-12-28 22:43:41
|
I'm thinking of adding a block to the bottoms of all files in the form: <? // $Log$ ?> What this would do is include the cvs log message every time a file is committed. I've found from work in the Real World that when a project is moved to a new cvs server, all the messages are lost. To make this even more pertinent would be: for each file in PhpWiki, add the block, plus all cvs messages for that file to date. This could be done by me by hand, over time, or perhaps there is a way to do this programmatically (probably a convoluted one-off Perl script). If anyone objects please let me know. Below is a much longer explanation from the red bean cvs book. ~swain $Log$ ==> accumulating log messages for the file, expands to ==> $Log: hello.c,v $ Revision 1.2 1999/07/26 06:47:52 jrandom ...and this is the second log message. Revision 1.1 1999/07/26 06:39:46 jrandom This is the first log message... The $Log$ keyword is the only one of these that expands to cover multiple lines, so its behavior is unique. Unlike the others, it does not replace the old expansion with the new one, but instead inserts the latest expansion, plus an additional blank line, right after the keyword (thereby pushing any previous expansions downward). Furthermore, any text between the beginning of the line and $Log is used as a prefix for the expansions (this is done to ensure that the log messages stay commented in program code). For example, if you put this into the file // $Log$ it will expand to something like this on the first commit: // $Log: hello.c,v $ // Revision 1.14 1999/07/26 07:03:20 jrandom // this is the first log message... // this on the second: // $Log: hello.c,v $ // Revision 1.15 1999/07/26 07:04:40 jrandom // ...and this is the second log message... // // Revision 1.14 1999/07/26 07:03:20 jrandom // this is the first log message... // and so on: // $Log: hello.c,v $ // Revision 1.16 1999/07/26 07:05:34 jrandom // ...and this is the third! // // Revision 1.15 1999/07/26 07:04:40 jrandom // ...and this is the second log message... // // Revision 1.14 1999/07/26 07:03:20 jrandom // this is the first log message... // You may not want to keep your entire log history in the file all the time; if you do, you can always remove the older sections when it starts to get too lengthy. It's certainly more convenient than running cvs log, and it may be worthwhile in projects where people must constantly read over the logs. |
From: Carsten K. <car...@us...> - 2002-12-31 21:01:29
|
Hi Steve, I added a $Log$ to my last commit of lib/plugin/PhpWeather.php, is that what you had in mind? Feel free to reposition it or reformat it; I more or less arbitrarily chose that spot but thought to keep it above the emacs tags. Also just to be safe I word wrapped my comments in emacs before committing, not sure if word-wrap is automatically handled. Carsten On Saturday, December 28, 2002, at 05:43 pm, Steve Wainstead wrote: > I'm thinking of adding a block to the bottoms of all files in the form: > > <? > // $Log$ > ?> |
From: Steve W. <sw...@pa...> - 2003-01-02 15:57:21
|
that's exactly what I had in mind. Thanks, Carsten! ~swain On Tue, 31 Dec 2002, Carsten Klapp wrote: > Hi Steve, > I added a $Log$ to my last commit of lib/plugin/PhpWeather.php, is that > what you had in mind? Feel free to reposition it or reformat it; I more > or less arbitrarily chose that spot but thought to keep it above the > emacs tags. > > Also just to be safe I word wrapped my comments in emacs before > committing, not sure if word-wrap is automatically handled. > > Carsten > > On Saturday, December 28, 2002, at 05:43 pm, Steve Wainstead wrote: > > > I'm thinking of adding a block to the bottoms of all files in the form: > > > > <? > > // $Log$ > > ?> > > > > --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa |
From: Jeff D. <da...@da...> - 2003-02-21 19:26:45
|
On Sat, 28 Dec 2002 17:43:38 -0500 (EST) Steve Wainstead <sw...@pa...> wrote: > > I'm thinking of adding a block to the bottoms of all files in the form: > > <? > // $Log$ > ?> > > What this would do is include the cvs log message every time a file is > committed. I've found from work in the Real World that when a project is > moved to a new cvs server, all the messages are lost. ... > If anyone objects please let me know. Below is a much longer explanation > from the red bean cvs book. ... I'm catching up on mail ... My feelings on this: o This is going to make the PhpWiki source bigger than it already is! It's already very big. The .php files gets loaded/parsed every time a page is viewed --- though I doubt the log comments contribute much to the load time, they don't help either. o In other projects, I've always found a global ChangeLog to be much more useful. I personally prefer the GNU-style, manually generated ChangeLog --- since then the whole log is tailored to be human readable. One simply has to grep the file to find notes of interest. (Of course, all the developers have update the ChangeLog, or else...) An example would be: ==== 2003-02-20 Geoffrey T. Dairiki <da...@da...> Have implemented the ability to cache marked up page text. (Had this been a real ChangeLog, I should have expounded a bit more here...) * lib/CachedMarkup.php: New file. * lib/main.php(main): Query-arg hook 'nocache' to disable markup cache. Use 'nocache=1' to disable reading the cache, 'nocache=purge' to clear the cache for the requested page. * lib/BlockParser.php: Changes for cached markup. Tweaks of list tightness logic. * lib/display.php: Minor fixes for new cached markup. * lib/loadsave.php: ditto * lib/XmlRpcServer.php: ditto * lib/plugin/RecentChanges.php: ditto * lib/plugin/IncludePage.php: ditto * lib/plugin/UnfoldSubpages.php: ditto * lib/plugin/SiteMap.php: ditto * lib/plugin/OldStyleTable.php: ditto * lib/stdlib.php(LinkBracketLinks): Moved to InlineParser. * lib/InlineParser.php: see above New class DebugTimer to help in execution profiling. * lib/main.php: Moved debug timing to prepend.php * lib/prepend.php(DebugTimer): New class. * lib/plugin/AllPages.php: Use DebugTimer for timing. * lib/plugin/AllUsers.php: ditto * themes/default/templates/debug.tmpl: ditto ==== Using a manually generated global changelog like this makes working off-line on large changes easier. Suppose I spend a couple days/week/months adding some big new feature to PhpWiki. When I go to check my changes in to CVS, I find I've touched nearly all of the files in the lib/ subdirectory. It's a big pain to check these in one at a time, and come up with diff each one to come up with useful CVS log entries for each one, so I'm likely to check them all in at once with some message like: "Big Change! Added new XXX feature." If I'd just been keeping my local copy of ChangeLog up-to-date as I hacked, and if there were a global ChangeLog in CVS, all I have to do is merge the two and then the global ChangeLog is again meaningful... Anyhow, my personal vote would be: no $Log$ in individual source files. Move over to (enforced by public flogging) use of a GNU-style global ChangeLog. |