Re: Processing CVS errors
Nope. You gotta look at standard error as well as the return code. Also cvs diff doesn't always return what you think it should either ;) donald On Thu, Dec 14, 2000 at 12:56:21AM -0800, Reinstein, Shlomo wrote: Hi, Is there some way to process CVS errors in software, other than reading the text describing them from the standard error? I have Perl scripts which make extensive use of CVS, and I'd like these scripts to be able to process CVS errors and try to recover. I can see that CVS exits with a 0 return value for success and 1 for failure, but I'd like to know (within the Perl scripts) the reason for the failure and try to process them in some way. Thanks in advance, Shlomo. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS + ssh == hack
I was looking for a secure cvs solution a while back and came across the cvs+ssh howtos. However it seemed a fairly nasty, if workable solution. I found a much better one however in the form of the sslserver patch (for the client) and sslwrapper (for the server) You get all the ease of use of pserver with security and without messing about with 'sleeping beauty' shells. I'd love to see the patch make it into the main cvs tree. Are any of the developers interested? Stephen. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Repository management
Jason Henry Parker wrote: 2. Alternatively, is it possible to tweak CVSROOT/ to make some directories readable or writable by only some users, or do I have to resort to messing with UNIX file permissions? I usually opt to use UNIX file permissions. It's pretty simple. Aside from setting the read/write permissions as you like you just have to set the setgid bits. You'll have to set LockDir in the CVSROOT/config file too. The LockDir needs to be writable by everyone and will usually need the setgid bit too. 3. The CVS book says CVSROOT/ needs to be writable by everyone. My plan is to make CVSROOT/ writable by world, and all the files (except CVSROOT/history) writable only by a cvsadmin user. At least with LockDir set, CVSROOT only has to be readable by everyone. I think only the history file needs to be writable by everyone. I'd be careful here, too. I think if a directory has write permissions by everyone, turning off write permissions on individual files in the directory is pretty pointless since anyone with write permissions to the dir can delete any file and replace it with a file of their choosing. I think everyone may get chmod abilities on all files in the dir too. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- This punishment is not boring and pointless. This punishment is not boring and pointless. This punishment is not boring and pointless... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit mail
[EMAIL PROTECTED] wrote: Hi I am a CVS newbie.I wanted to know how I can send many commit messages as a single email;i.e. I want to send 10 commits as 1 email message. I also want to know how I can configure loginfo to send mail at a specified time i.e. once an hour or two. Thanks, Jeeva Sarma Look into the scripts in the contrib directory of the source distribution. I think a commit_prep.pl log_accum.pl pair are supposed to do something like you're asking but I haven't played with them myself. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Of all the gin joints in all the towns in all the world, she walks into mine. - Humphrey Bogart as Rick, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to: SSH CVS Linux(server) Win(client[s])
Robert Schott wrote: cvs:/home/validuser/.ssh/autorized_keys - I even tried a 'ssh -l validuser cvs' and this worked!) As I understand it, the command above would attempt to log into a host with the hostname 'cvs'. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Take my advice, I don't use it anyway. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Processing CVS errors
Donald Sharp wrote:
Nope. You gotta look at standard error as well as the return code.
Also cvs diff doesn't always return what you think it should either ;)
donald
On Thu, Dec 14, 2000 at 12:56:21AM -0800, Reinstein, Shlomo wrote:
Hi,
Is there some way to process CVS errors in software, other than reading the
text describing them from the standard error? I have Perl scripts which make
extensive use of CVS, and I'd like these scripts to be able to process CVS
errors and try to recover. I can see that CVS exits with a 0 return value
for success and 1 for failure, but I'd like to know (within the Perl
scripts) the reason for the failure and try to process them in some way.
Thanks in advance, Shlomo.
Shlomo,
I have been writing Perl scripts to interact with CVS and examine the results
including output to standard error.
Some examples, completely out of context are shown below:
---
Testing if nothing present to commit or no CVS Entries present from
a cvs -nq update
$count = @result = `cvs -nq update 21`;
if ($count == 0) {
print colored ("Nothing to commit\n", 'red on_yellow');
return 0;
}
$count = @result2 = grep /update aborted/, @result;
if ($count == 1) {
print colored ("No CVS Entries presents\n", 'red on_yellow');
return 0;
}
---
This is how I get the new and previous version after a commit so that
I can do a rtag on the new version:
@result2 = `cvs -q commit -m\"$scr\" $_`;
($file) = grep /Checking in/, @result2;
$file =~ s/Checking in (.*)\;$/$1/;
($new_rev) = grep /new revision:/, @result2;
chomp $new_rev;
$new_rev =~ s/.*new revision: ([\d\.]*); previous.*$/$1/;
@result2 = `cvs rtag -F -r $new_rev $scr $file`;
print colored (" @result2", 'magenta on_white');
---
They might give you some ideas.
Dale Miller
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: loginfo - keeping a checked out copy
Thank you.
Actually, I figured out the problem...if I put both the call to log.pl
(which should go first) and the cvs update in parens, it works.
thanks all,
Kelleigh
-Original Message-
From: Derek R. Price [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 14, 2000 9:32 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: loginfo - keeping a checked out copy
The log.pl script relies on some of hte information which you are
slurping and writing out with the 'cat' following 'date' below. The
solution is to call an intermediate script which reads in stdin and
writes it out to two separate child processes (below, the
simple echo to
the log log.pl). Alternately, you could hack log.pl to write to the
text log as well as to send the mails.
Derek
--
Derek Price CVS Solutions Architect (
http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Always glad to share my ignorance - I've got plenty.
[EMAIL PROTECTED] wrote:
I'm having a bit of difficulty with loginfo
we're set up to have our webpages update automatically when a checkin
is done - I've got that working (from Cedarqvist). I also use the
log.pl to send the CVS commit mails out.
Is there some way to have both actions perform for one checkin?
At first I could only get either the updates or the mail. Now I get
the update and mail, but it doesn't seem to be coming from the log.pl
as it's only giving the directory the change was made and the author.
It's not giving the modified filename or the comments.
here's the line out of my loginfo file:
^docs ((date; cat; (sleep 2;
cd /workspace1/cvstree/docs; /usr/local/bin/cvs -q update -d) )
/workspace1/cvstree/docs/updatelog.txt 21
; $CVSROOT/CVSROOT/log.pl %s -u ${USER} -m [EMAIL PROTECTED] -f
$CVSROOT/CVSROOT/docs.log -s)
what am I doing wrong?
ADVthanksANCE,
Kelleigh
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: how to: SSH CVS Linux(server) Win(client[s])
cvs:/home/validuser/.ssh/autorized_keys - I even tried a 'ssh -l validuser cvs' and this worked!) As I understand it, the command above would attempt to log into a host with the hostname 'cvs'. Derek, yes this is correct. Yesterday night I successfully took the cygwin solution to work. But there is a bad taste in there: a) I still don't understand exactly what goes on in there (grin yes I have to read on... a matter of time). I have the problem not to know the syntactical things for tunneling. At the moment I fixed the environment variables but I really would like to know how to do it COMPLETELY at the command line. That's the point. and.. b) The Windows ME DOS box (webdave) I used for testing purpose shows a nasty thing when using ssh. Because CVS uses SSH internally and cygwin SSH does not terminate gracefully after any CVS write cmd. The communication hangs forever when it finishes. But the files are there when interrupting with Ctrl-C. I tried as suggested UsePrivilegedPort no in config file but that does not help, either. I wondered when scp'ing from client to linux host. The file was there but I had to Ctrl-C the cmd, to get back to the DOS prompt. Another guy told me he has some similar effects seen on a Win2k machine. So it seems to be a general problem. This effect is reproduceable at this machine. Did not test it with 98/95, yet - maybe in near future. Only clean solution seems not to use Windows world. Well, maybe in some days... currently it is not possible. Robert ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SV: Different kind of access methods
Richard Cobbe writes [quoting me]: Doing :local: access to an nfs/smb/samba mount repository frequently doesn't work reliably at all, which is why it is discouraged. Why is this? In particular, what sort of problems can one encounter when using this sort of system? (Is it perhaps related to the lockfiles CVS uses to prevent multiple people from modifying the repository at the same time?) There is a potential locking problem with NFS (although no one has ever reported it actually occurring in practice), but it only causes denial of service -- a client can create a lock without knowing it so the lock will never be cleared -- not loss of data. The more serious problem is that most implementations are buggy. The bugs tend to be interoperability bugs -- as long as all the machines are running the same code, everything works fine, but when you try to mix different systems things start to go wrong and both vendors insist that the problem must be with the other system. If the bugs cause immediately noticeable errors, then it's annoying (perhaps to the point of unusability), but at least you don't lose any data. Unfortunately, it's not uncommon for the bugs to instead cause a chunk of data in the middle of a repostory file to be replaced with NUL bytes. Because of the way the RCS file format works, it's entirely possible that you won't notice the corruption for quite some time and there's a good possibility that when you do notice it, you'll no longer have any backup copies old enough to recover the lost data. -Larry Jones Hey Doc, for 10 bucks I'll make sure you see those kids in the waiting room again real soon! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Processing CVS errors
Reinstein, Shlomo writes: Is there some way to process CVS errors in software, other than reading the text describing them from the standard error? The best way to do that is to use the client/server protocol rather than using the CVS command. Unfortunately, that is not a small task. -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SV: Different kind of access methods
I had heard that mkdir under NFS is not an atomic operation. If this is true, then CVS locks won't be atomic either, thereby making it possible for two developers to checkin the same things at the same time -- this would be very bad. Noel [EMAIL PROTECTED] on 2000.12.14 10:42:01 To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Noel L Yap) Subject: Re: SV: Different kind of access methods Richard Cobbe writes [quoting me]: Doing :local: access to an nfs/smb/samba mount repository frequently doesn't work reliably at all, which is why it is discouraged. Why is this? In particular, what sort of problems can one encounter when using this sort of system? (Is it perhaps related to the lockfiles CVS uses to prevent multiple people from modifying the repository at the same time?) There is a potential locking problem with NFS (although no one has ever reported it actually occurring in practice), but it only causes denial of service -- a client can create a lock without knowing it so the lock will never be cleared -- not loss of data. The more serious problem is that most implementations are buggy. The bugs tend to be interoperability bugs -- as long as all the machines are running the same code, everything works fine, but when you try to mix different systems things start to go wrong and both vendors insist that the problem must be with the other system. If the bugs cause immediately noticeable errors, then it's annoying (perhaps to the point of unusability), but at least you don't lose any data. Unfortunately, it's not uncommon for the bugs to instead cause a chunk of data in the middle of a repostory file to be replaced with NUL bytes. Because of the way the RCS file format works, it's entirely possible that you won't notice the corruption for quite some time and there's a good possibility that when you do notice it, you'll no longer have any backup copies old enough to recover the lost data. -Larry Jones Hey Doc, for 10 bucks I'll make sure you see those kids in the waiting room again real soon! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SV: Different kind of access methods
Noel L Yap writes: I had heard that mkdir under NFS is not an atomic operation. If this is true, then CVS locks won't be atomic either, thereby making it possible for two developers to checkin the same things at the same time -- this would be very bad. It depends on how you look at it. It's probably more accurate to say that mkdir is atomic but not idempotent; that is, mkdir *on the server* is an atomic operation -- which means that there is no chance of two different CVS clients thinking they both own the same lock -- but if the client repeats the operation (which it will if it doesn't receive the reply from the server for some reason) it will fail and the client will think that it doesn't own the lock when it really does. This leads to denial of service since you have a lock that will never get deleted, but it can't cause data corruption. -Larry Jones These pictures will remind us of more than we want to remember. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Performance
What can be done to improve the performance of CVS? Is this topic already covered on some website or FAQ. We use pserver to connect to a remote RedHat machine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs history error...
Howdy -- granted we have a 680MB history file. Could that be why I'm getting this error? cvs history -T -a olfmake.defs Terminated with fatal signal 11 cvs -v Concurrent Versions System (CVS) 1.10.8 (client) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS The history file is sitting on a Solaris machine with cvs 1.10.8 server. Most of the history file was created with cvs 1.9.x, could that be the problem? And what is a fatal signal 11, anyway? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Performance
James Stauffer writes: What can be done to improve the performance of CVS? Is this topic already covered on some website or FAQ. We use pserver to connect to a remote RedHat machine. I don't know of anything specifically about CVS, but it's pretty much like any other tuning process. First, you have to define what you mean by "improve the performance": are you just interested in improved response time or are you interested in reducing its system resource usage (e.g., physical memory, swap space, disk space, etc.)? What is it that's slow: checkouts, checkins, etc.? What is taking up all the time: the client process, the server process, or the network communications? If the client and server machines are fast but the network connection is slow, you may want to use the global -z option to compresses the network traffic; if the network is fast but one or both machines are slow, you probably don't want to use -z. If the problem is the client or server process or both, what is making it (or them) slow: are they not getting enough CPU time, are they spending lots of time waiting for I/O, are they spending lots of time paging or (heaven forbid) swapping? For general tuning information, I recommend "System Performance Tuning" by Mike Loukides (O'Reilly Associates, www.ora.com). -Larry Jones I take it there's no qualifying exam to be a Dad. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs history error...
Robert Bresner writes: granted we have a 680MB history file. Could that be why I'm getting this error? cvs history -T -a olfmake.defs Terminated with fatal signal 11 Signal 11 is SIGSEGV (segmentation violation) which is frequently caused by running out of memory. Are you sure the server is running CVS 1.10.8 and not some earlier version? Versions prior to 1.10.8 read the entire history file into memory at once, so that could explain the problem (although CVS should have reported being out of memory rather than crashing with a signal). 1.10.8 and later read the history file a chunk at a time and only save the individual records you're interested in, so they're much less likely to exhibit the problem, although it is still possible. How much virtual memory do you have available on the server? -Larry Jones Years from now when I'm successful and happy, ...and he's in prison... I hope I'm not too mature to gloat. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS + ssh == hack
I forgot to give the URL of the client cvs ssl patch: http://konst.org.ua/eng/software/other/info.html And the url of the server side: http://www.rickk.com/sslwrap Stephen. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs history error...
Robert Bresner wrote: Howdy -- granted we have a 680MB history file. Could that be why I'm getting this error? cvs history -T -a olfmake.defs Terminated with fatal signal 11 cvs -v Concurrent Versions System (CVS) 1.10.8 (client) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS The history file is sitting on a Solaris machine with cvs 1.10.8 server. Most of the history file was created with cvs 1.9.x, could that be the problem? And what is a fatal signal 11, anyway? According to my POSIX.1 spec, signal 11 is SIGSEGV. If it has to do with running out of memory, something not improbable with a 680MB history file, I would think that a NULL pointer returned by a bad alloc call had been accessed, but those are usually hard to get with CVS due to the way it allocates memory. Of course, I suppose it's also possible that cvs 1.10.8 expects a history line longer that 1.9 provides or some such, though I haven't heard of this coming up in the past. Can you send me a debugger backtrace from the core your server dumped? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- A cubicle is just a padded cell without the door. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SV: Different kind of access methods
On Wed, Dec 13, 2000 at 08:21:15PM -0600, Richard Cobbe wrote: I should probably have been clearer---our repository is currently on a disk that we mount via NFS. What are the issues involved with that specific situation? Buggy NFS implementations. Client and server. Not to mention performance. One particular item I've seen is Linux's buggy user space nfsd, especially with dealing with nfsd exporting two partitions (in my case, /usr and /usr/src were two partitions on the server, but exported simply as /usr). I could reliably (that is, it would break in exactly the same spot each time), by doing a rather large co (test case I used was a series of cvs imports for the entire historical linux binutils releases). What I was seeing was a file turning into a directory, or vice-versa. (I imagine it had something to do with an inode in the cvs repository matching an inode in something like /usr/bin, and the client getting all confused). Granted, this was a Linux bug. But it definitely shows the potential problems. And getting back to performance, the client (nfs/smb/nw) has to open/read/write/close the entire archive file. This sucks over a networked file system. Better to let the local machine do all the accessing and send you just the pertinent parts. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Performance
Performance can be addressed several ways. If you have a somewhat large module, but you only need a subset of it, consider either breaking the module up into smaller modules or creating entries in the modules file such that when you perform a "cvs get module" you are only receiving what you need. The caveat is that if you are using a "module" defined in the modules file as opposed to a module under $CVSROOT, then you should use "cvs update -d" only where necessary to pickup new directories. Otherwise you will be picking up all of the directories that the original "cvs get" didn't picked up whether you wanted them or not, thereby negating the reason you setup the modules file entry. Bottlenecks to the CVS server are usually, in order of severity, network, disk I/O and finally CPU (sometimes memory). Having a good admin that can monitor what is happening and make the appropriate tuning tweaks and recommendations is invaluable. Methods of increasing network throughput for your specific needs can differ for almost every case. It is important to understand where the network bottlenecks exist. I have done several things over the years to improve network performance, such as re-segmenting the network, replacing hubs with switches, replacing 10Base-T equipment with 100Base-T, using dedicated IP addresses for specific applications, purchasing faster dedicated lines between sites, dedicating a minimum percentage of network bandwidth for a specific application. However, in each case it was specific to the situation. There is rarely a one size fits all solution and cost can play a major factor. I would suggest talking to the appropriate person in IT/MIS to see what can be done. There are a whole host of disk I/O solutions as well. For the most part, most of the disk intensive servers I setup, I use hardware RAID setup with RAID 0+1 (striping over separate SCSI channels), using the fastest drives and fastest I/O solution I can get. If users will tend to be reading and writing many of the same files and directories, you might look into storage solutions that provide battery backed cache (not cheap). If your CPU or memory bound you may want to try tuning the system and/or upgrading. Hope this helped. -Scott Pyatt -Original Message- From: James Stauffer [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 9:49 AM To: [EMAIL PROTECTED] Subject: Performance What can be done to improve the performance of CVS? Is this topic already covered on some website or FAQ. We use pserver to connect to a remote RedHat machine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Multiple developers in one work area
Hello, I'd like to setup CVS for a web based project that involves multiple developers. We would like to have those multiple developers access the same directory of source code, as opposed to each having their own working area. The reason behind this is that everyone needs to use the same web server for testing, and hence the same working area. In traditional situations, each developer is able to build and test the project in their own working area. With the web based project, there is no build process as such, and testing requires a fairly complex setup. Therefore, we would like to share a common code area, and access the files with RCS locking style to avoid trampling on each other's work. Why not just use RCS? CVS offers better branching facilities, as well as better web integration, etc. Given that scenario, can CVS be used? I'd like the files to be read-only, and made available for editing only after a "cvs edit". This works fine with "watch on", but when the second developer tries to "cvs edit" files we run into permission problems, since the files are owned by the 1st developer. I've tried playing with permissions, but haven't hit a combination that works. Any ideas? Best, Parand Tony Darugar ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs history error...
Larry Jones wrote: Are you sure the server is running CVS 1.10.8 and not some earlier version? Pretty sure. I have this alias: alias cvs='/usr/local/ultra/cvs-1.10.8.stripped' I have this in my home dir: lrwxrwxrwx 1 rbresner staff 36 Dec 11 16:15 cvs - /usr/local/ultra/cvs-1.10.8.stripped Also, when I tried doing CVS history commands with the older cvs (1.9.x) it would die immediately with "out of memory" errors. With 1.10.8, the history command will sit for a long long while trying to get through our history, then it will die with the signal 11. How much virtual memory do you have available on the server? There is 256MB memory, 1GB virtual memory. The history file is 619918470 bytes. Egads. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs scripts
Howdy -- I wrote a perl script sometime back that will format the output of a cvs status. It takes a bunch of +/! options to turn on or off the info you'd rather see Depending on the method of execution, it will either parse a 'cvs -n update' or cvs status (-F), or, it will compare timestamps of files against the timestamps reported in the CVS/Entries files (-B). If there's any interest, I can post it as an attachment to the list. To wit: == cvstat Sticky Tag Status File Locally Modified cdd.bat Locally Modified cvlog Locally Modified cvstat.bat Needs Update cvsu Locally Modified hmake.bat *Needs Merge make_release Locally Modified makelocal.bat Locally Modified mktemplate Locally Modified ophone.bat Locally Modified runolfscript cvstat -h cvstat prints status and sticky tags from cvs. -r tag report deviations from this tag (Also for Blazingly Fast Mode(tm) ) -B Blazingly Fast Mode(tm). It really is fast, ya know. -l do not recurse -t|-tt display start|finish time -c hide tags column when not showing tags -L display single-line file list at end for easy cut'n'paste -F Fast-Stat. WARNING: Does not report "needs first checkout" files -q quiet-mode. Hide warnings, only show errors. -o diplay filename info only, no tags, no headers, no status. -z# passed on to CVS. Sets the compression level on communications with the server. -i Ignore CVSTAT_ARGS -b Do not display the branch revision when +T -d cvsroot set CVSROOT to something other than its current value -R use CVSROOT env var with -d -s VAR=VAL set some other cvs var to a value -st sort by TAG -ss sort by STATUS -sf sort by FILENAME -h display this help message The following status options can be used in combinations ! turns off the following ... + turns on the following ... U display up-to-date files (default: Off) M display locally modified files (default: On) A display locally added files (default: On) R display locally removed files (default: On) C display files with conflicts (default: On) P display files that need patch|checkout (default: On) T display sticky tag info. (default: Off) Q display files not in cvs repository (default: Off) !! Turns off all everything. Useful first option. ++ Turns on everything. useful first option. Example useful commands: cvstat +TU !ARCMPdisplays only files up-to-date and the sticky tags cvstat +MARC !P displays files you want to check in cvstat !! +Q show only the unknown files cvstat ++ !M show everything except locally modified files When using -o option, only filenames are displayed (useful for shell scripts). Beware that all files matching the status options are displayed. When using -o is a good time to specify the status options. If sorting is turned on, the whole process takes a little longer, even with -F Command line args override CVSTAT_ARGS args Blazingly Fast Mode only reports locally modified files. It does not check against the repository, so cannot determine if a file is out-of-date. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
