Menu
▾
▴
nms-cgi-devel
|
From: Olivier D. <dr...@sh...> - 2002-02-01 14:28:43
|
Hi everyone, I was just wondering if people has figured out how to have cvs put the log in a different file, or if anything has been tried. On a related note, I've changed the header skeleton (see below). Please have a look at it and let me know if it's good. If nobody complains I'll make the changes tomorrow. If the log issue isn't resolved I'll simply put this right after the log (except for #!). #!/usr/bin/perl -wT ######################################################## # PROGRAM INFORMATION # ------------------- # ProgramName.pl v1.2.3.4.5.6... # # This program is licensed in the same way as Perl # itself. You are free to choose between the GNU Public # License <http://www.gnu.org/licenses/gpl.html> or # the Artistic License # <http://www.perl.com/pub/a/language/misc/Artistic.html> # # For a list of changes see CHANGELOG # # For help on configuration or installation see README # use strict; use ...; . . . # # USER CONFIGURATION SECTION # -------------------------- # Modify these to your own settings. You might have to # contact your system administrator if you do not run # your own web server. If the purpose of these # parameters seems unclear, please see the README file. # my $param = "stuff"; # Will be used for stuff my $baseurl = "/var/www"; # Server's web documents directory my ...; . . . # # USER CONFIGURATION << END >> # ---------------------------- # (no user servicable parts beyond here) *code* -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Wizard <wi...@ne...> - 2002-02-01 14:58:56
|
> # USER CONFIGURATION << END >> > # ---------------------------- > # (no user servicable parts beyond here) You forgot "servicable" (spelling - should be serviceable). Grant M. |
|
From: Olivier D. <dr...@sh...> - 2002-02-01 19:50:13
|
How's this? #!/usr/bin/perl -wT use strict; use ...; . . . # PROGRAM INFORMATION # ------------------- # ProgramName.pl v1.2.3.4.5.6... # # This program is licensed in the same way as Perl # itself. You are free to choose between the GNU Public # License <http://www.gnu.org/licenses/gpl.html> or # the Artistic License # <http://www.perl.com/pub/a/language/misc/Artistic.html> # # For a list of changes see CHANGELOG # # For help on configuration or installation see README # # USER CONFIGURATION SECTION # -------------------------- # Modify these to your own settings. You might have to # contact your system administrator if you do not run # your own web server. If the purpose of these # parameters seems unclear, please see the README file. # my $param = "stuff"; my $baseurl = "/mywebpage"; my ...; . . . # # USER CONFIGURATION << END >> # ---------------------------- # (no user serviceable parts beyond here) *code* On Fri, Feb 01, 2002 at 12:44:55PM -0500, Joseph F. Ryan wrote: > I really don't like that first ################### line; also, i think you > should bring "use strict" to under the shebang > > At 09:33 AM 2/1/2002 -0500, you wrote: > >Hi everyone, > > > >I was just wondering if people has figured out how to have cvs put the > >log in a different file, or if anything has been tried. > > > >On a related note, I've changed the header skeleton (see below). > >Please have a look at it and let me know if it's good. If nobody > >complains I'll make the changes tomorrow. If the log issue isn't > >resolved I'll simply put this right after the log (except for #!). -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
|
From: Jonathan S. <gel...@ge...> - 2002-02-02 10:13:24
|
On Fri, 1 Feb 2002, Olivier Dragon wrote: > > I was just wondering if people has figured out how to have cvs put the > log in a different file, or if anything has been tried. > I would guess that nothing has been tried because, unless I have missed something fundamental about CVS (and I don't think so), anything that happens automatically to the file happens on the server side and can't create or update local files apart from those that are being updated in the repository. Personally as a *developer* I would prefer to have the change logs in the files that are being edited, and as a *manager of developers* (in the real world) I would like it that the change logs are present in the files while they are being actively developed. This is so that a programmer, on opening a file for editing, will see (hopefully) what the last committed action on that file was - this may prevent reduplication of work or breakage due to cross purposes, it may help in the diagnosis when something that is being added to the code doesnt work as expected. I don't know about anyone else but I don't always find it easy reading other peoples code and seeing the changes in code almost impossible. Now this possibly at variance with the other aims of the project, so I would suggest that we keep the Log entries in the file and have them removed to a Changes file when a release - the average punters shouldn't be using the CVS versions as they are probably broken and almost certainly incomplete ... /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |
|
From: Wizard <wi...@ne...> - 2002-02-02 12:12:21
|
> I was just wondering if people has figured out how to have cvs put the > log in a different file, or if anything has been tried. There's a CVS admin file called 'loginfo', which I believe does what you are expecting. It's purpose is to run a program at every commit. I've never used it, so you're on your own. Here's an excerpt from the man: (http://www.cvshome.org/docs/manual/cvs_18.html#SEC169) ==== Excerpt ========================================= The following `loginfo' file, together with the tiny shell-script below, appends all log messages to the file `$CVSROOT/CVSROOT/commitlog', and any commits to the administrative files (inside the `CVSROOT' directory) are also logged in `/usr/adm/cvsroot-log'. Commits to the `prog1' directory are mailed to ceder. ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log ^prog1 Mail -s %s ceder The shell-script `/usr/local/bin/cvs-log' looks like this: #!/bin/sh (echo "------------------------------------------------------"; echo -n $2" "; date; echo; cat) >> $1 Grant M. |
|
From: iain t. <ic...@eh...> - 2002-02-02 12:40:18
|
* Wizard (wi...@ne...) [02 Feb 2002 23:30]: > > I was just wondering if people has figured out how to have cvs put > > the log in a different file, or if anything has been tried. > There's a CVS admin file called 'loginfo', which I believe does what > you are expecting. It's purpose is to run a program at every commit. > I've never used it, so you're on your own. Here's an excerpt from the > man: Personally, I think a 'project build' script. i.e. one runs the script and it 'cvs export's the project files and does a 'cvs log' of the project as well and pipes that to a file in the project dir (but not a cvs'd file). Ideally, it would then tar.gz and zip the dir and upload them to the sourceforge pages. This way, if we wanted to release a new version it would merely involve someone running the script. Similar with the FAQ and so on. Should just be scripted. Of course, the FAQ's script could be put into the CVS to be automatically run on commits. It's possibly an XP tenet, but it's definitely a generic good practice tenet: make everything automated. It reduces the chance of errors and removes the tedium of making releases. Comments? Volunteers? -- iain. <http://eh.org/~koschei/> |
|
From: Olivier D. <dr...@sh...> - 2002-02-02 19:55:06
|
On Sat, Feb 02, 2002 at 10:13:12AM +0000, Jonathan Stowe wrote: > Now this possibly at variance with the other aims of the project, so I > would suggest that we keep the Log entries in the file and have them > removed to a Changes file when a release - the average punters shouldn't > be using the CVS versions as they are probably broken and almost certainly > incomplete ... This sounds like a reasonable and convenient idea. So we leave the scripts the way they are, change the headers (after the log) and whenever we make a release we take out the log and put it in a seperate file so we end up with a clean, easy to configure script AND developers know what's going on. Good suggestion. I'm for it. -Oli -- +----------------------------------------------+ | Olivier Dragon dr...@sh... | | Software Engineering II, McMaster University | +----------------------------------------------+ |
Thanks for helping keep SourceForge clean.
X