Re: Updating from parent directory
Craig Dickson writes: > > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="===37948206652389782==" Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! > I would like to be able to run the update command on a particular > subdirectory (ie. branch) without having to go into that directory to do > it. Is there a way? I keep getting errors on the command line with the > various permutations of arguments I have attempted so far. ``cvs up '' should work -- what error do you get? -Larry Jones Sheesh. Who can fathom the feminine mind? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Updating from parent directory
I have a parent directory that contains multiple child directories, each child contains the content of a different branch of the same module (the directory names are the same as the branch names). The parent directory is not under CVS control. I would like to be able to run the update command on a particular subdirectory (ie. branch) without having to go into that directory to do it. Is there a way? I keep getting errors on the command line with the various permutations of arguments I have attempted so far. Thanks, Craig ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: What is a good Windows CVS client?
> It's unsurprising that a POSIX program ported straight to an > independently developed, properly done POSIX layer performs > better than a version of that program hacked to directly > target the platform. On the contrary, I am somewhat surprised. Cygwin is wonderful, but there is a definite overhead to the POSIX emulation layer when it comes to being careful about the semantics. For instance, a "cp -rp" by Cygwin is noticeably slower than XCOPY or even MKS' pure-native port of "cp". I wonder if there are other factors at work here (e.g. line-ending conversion, etc. - was the Cygwin version just writing out Unix line endings (no conversion) whereas the native CVS was, or something?). Unfortunately I'm not near my repository where I can do a reasonable comparison (access over the WAN will swamp the readings), but I can try this next week and see which is faster given a level playing field. Still, either way, either Windows port of CVS will be slower than a Linux CVS. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Changes since a tag but only the revision and check in comments
Tony Obermeit writes: > > How can I obtain a list of changes that have occurred since a tag to the > latest version, I want to see the revision and check in comments only. You want rlog, not rdiff. -Larry Jones I keep forgetting that rules are only for little nice people. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: What is a good Windows CVS client?
[EMAIL PROTECTED] (Sandeep Gupta) wrote in message news:<[EMAIL PROTECTED]>... > We have a repository that is 124MB of ,v files. The checkout is 92MB. > The server is running on Redhat 8.0 with CVS version 1.11.2. > > All clients are using pserver. > > A checkout from a Redhat 8.0 client takes 30 - 45 seconds for a clean > checkout (no preexisting files on the local machine) > > A checkout on Windows XP using cvs.exe from cvshome.org takes over 3 > minutes for a clean checkout! > > We tried using cygwin's cvs and it is about 25 - 50% faster. It's unsurprising that a POSIX program ported straight to an independently developed, properly done POSIX layer performs better than a version of that program hacked to directly target the platform. (By the way, what do you mean by 50% faster? 50% faster than 3 minutes is 2 minutes). > Why are the Windows XP clients so much slower? Because Windows XP is a poorly implemented, slow operating system kernel with sluggish filesystem operations? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Changes since a tag but only the revision and check in comments
How can I obtain a list of changes that have occurred since a tag to the latest version, I want to see the revision and check in comments only. I've been using the following command: cvs -Q rdiff -s -r TAG module but all I'm getting is the revision numbers since the tag, I also want the check in comments. I don't want more than the revision and comments, when I take out the -s I get too much. Thanks Tony ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs on webserver set up question
Please forgive the rambling questions. I have used CVS previously, but am unsure of how to set it up in this environment. I have a web server that has multiple clients and I would like each client to be able to have their own cvs session (so they can not get projects created by other clients), is this possible/feasible? Also, how would I set up CVS so after files are modified and updated on the server they become "live" on the websites? Thanks for the help and again I apologize for the rambling questions. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
> Better would be to make the whole waiting > process use a random wait with exponential backoff; that should help avoid process > that have gotten in lockstep all trying to grab the master lock at the > same time. > Shades of Ethernet carrier sense multiple access/collision detection... seems to pop up all sorts of places Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Really a reserved checkout?
Ross Patterson writes: > > But, for example, CVS's peculiar vulnerability to NFS > errors isn't touched on at all, despite it being a critical issue. That's a good point, although CVS isn't alone -- I first ran encountered the problem in relation to my company's CAD/CAM/CAE software, which is how I recognized it so easily when CVS users started reporting it. > And while > the accepted wisdom on this list seems to be that vendor branches are a bad > way to import someone else's sources, they're the specificly recommended > technique in the doc. I don't think that's generally accepted (*I* certainly don't accept it). The vendor branch is an excellent way to import someone else's sources, that's what it was designed for! Some people do object to using it to import your own sources, but that seems to be more a visceral objection to the "strange" initial revision numbers (which you shouldn't be looking at anyway) than any real problem. -Larry Jones Physical education is what you learn from having your face in someone's armpit right before lunch. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Lock contention executing cvs log
MacDonald, Ian writes: > > While several of my build processes were running, I was monitoring the CVS > server with 'top'. I noticed a strange occurrence with two of cvs processes > that were currently executing a log command - both processes grew to consume > nearly all available memory (in my case 512MB). While this was occurring, > the cvs clients associated with these growing cvs processes started dumping > the 'waiting for blahs lock' messages to stdout. This went on for about 15 > minutes before the log commands completed. Does anyone know if this is > normal behavior? Probably. CVS can be quite memory intensive. Now, that's generally *virtual* memory, so it doesn't matter so much. If you were running a version of top that's similar to the one I have, SIZE is the amount of virtual memory a process is using, RES is the amount of real memory. You had to have been looking at SIZE rather than RES since it isn't possible for two processes to both be using nearly all the physical memory. Don't forget that virtual memory is paged rather than processes being swapped, so the two processes don't interfere with each other -- it's not necessary for one to wait for the other to release some virtual memory before it can procede. In fact, I suspect you'll find that the processes *never* release virtual memory; they start out growing, they may or may not eventually stabilize; if they do, they stay that size until they end; they never shrink. I think what you're seeing is, indeed, lock contention. Whichever process starts first has to actually read the data off the disk and is constantly stopping and waiting for that to happen. The second process, however, finds all the data it needs in the filesystem cache (courtesy of the first process) and thus can proceed much faster until it finally catches up. Once that happens, the two process procede more-or-less in lockstep and end up running into each other the next time they try to create read locks. Waiting for a lock is a very time consuming process -- the current code just sleeps for 30 seconds and then tries again. I just checked in a change that modifies the algorithm slightly. When contention is encountered, the code now makes a few retry attempts with a very short time wait time (initially 2 us with an exponential backoff) before giving up and going into the fullblown wait with messages and the 30 second wait. That should significantly reduce the impact of contention. In my test with two simultaneous log processes, there was lots of contention, but the second process usually got through after a single retry and never needed more than 3 (I allow up to 9 retries which is a total delay of about 1ms). Of course, if there's enough contention, you'll still end up in the old "30 second wait with a message" code. Better would be to make the whole waiting process use a random wait with exponential backoff; that should help avoid process that have gotten in lockstep all trying to grab the master lock at the same time. -Larry Jones I've never seen a sled catch fire before. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Really a reserved checkout?
On Friday 28 February 2003 12:55 pm, Brandon Craig Rhodes wrote: > Donald Sharp <[EMAIL PROTECTED]> writes: > > The cvs documentation is obtuse and hard to read. > > It might be more useful to say that the documentation is designed as a > reference - it will tell you everything there is to know about one > aspect of CVS, then progress to another. True for some things. But, for example, CVS's peculiar vulnerability to NFS errors isn't touched on at all, despite it being a critical issue. And while the accepted wisdom on this list seems to be that vendor branches are a bad way to import someone else's sources, they're the specificly recommended technique in the doc. > This is useful if you > already know how CVS works, but far less tractable a resource to > actually learn CVS from. True. The Fogel book (http://cvsbook.redbean.com) does a better job of teaching, although it's too much like "CVS for Dummies" for my taste. -- Ross A. Patterson Chief Technology Officer CatchFIRE Systems, Inc. 5885 Trinity Parkway, Suite 220 Centreville, VA 20120 (703) 563-4164 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
Title: RE: Lock contention executing cvs log (Hopefully this time at plain-text) - Sorry again Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald -Original Message- From: MacDonald, Ian [mailto:[EMAIL PROTECTED]] Sent: Friday, February 28, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: Lock contention executing cvs log Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 28, 2003 8:13 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Lock contention executing cvs log > > > MacDonald, Ian writes: > > > > MIME-Version: 1.0 > > Content-Type: multipart/mixed; > > boundary="===91921517666352637==" > > Please do not send MIME and/or HTML encrypted messages to the > list. Plain text only, PLEASE! > > > Shouldn't cvs simply be using "read" locks while executing the log > > command? > > It should, and it is. > > > If that's the case, why is there a contention for the "read" locks? > > Because you need an exclusive lock to create a read lock. > The exclusive lock is only held for a very short time (just > long enough to create the read lock), but it's still possible > for there to be contention for it. > > -Larry Jones > > I must have been delirious from having so much fun. -- Calvin > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -D question
Craig Dickson writes: > > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="===0030479026202012705==" Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! > If I have a file in CVS that has a revision with a modification time of > 2003-02-28 17:30:31 and I update my local working copy of the module > that that file is in and I pass the -D argument with the value > 2003-02-28 17:30:31, will that revision be included or will it be the > one before it? Did you try reading the manual? The description of -D says: Use the most recent revision no later than date. "No later than" implies that it is inclusive, which it is. Be aware, however, that CVS reports times in UTC (GMT) but takes user-entered times as being in local time if no timezone is specified. So, the correct argument value for the above would be "2003-02-28 17:30:31 UTC". -Larry Jones How many presents do you think I'd forfeit for just one clean smack upside Susie's head? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Lock contention executing cvs log
Title: RE: Lock contention executing cvs log Thanks Larry, Sorry for the MIME post. I realized that I forgot to turn it off after sending it (and you can't un-send a message). Not sure if you saw my follow up. But I'm now thinking that the lock contention is not the source of my performance problems, just a side effect. My theory is that the CVS processes are effectively serializing themselves by virtue of using up most of the available memory while they operate on a particular directory. When a large cvs process releases enough memory for another cvs process to operate freely, the new process runs into several of other cvs processes which were also now trying to do the same thing which is acquire a read lock on the next directory. Another clue is that I can start several build cycles on different hosts at random start times (15-20 minutes apart), but they eventually become synchronized and all finish within a few seconds of each other. I guess my question now is why the cvs processed grow so large. Can you characterize how cvs should behave with respect to memory allocations when performing a log command over a set of directories? Regards, -- Ian MacDonald > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 28, 2003 8:13 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Lock contention executing cvs log > > > MacDonald, Ian writes: > > > > MIME-Version: 1.0 > > Content-Type: multipart/mixed; > > boundary="===91921517666352637==" > > Please do not send MIME and/or HTML encrypted messages to the > list. Plain text only, PLEASE! > > > Shouldn't cvs simply be using "read" locks while executing the log > > command? > > It should, and it is. > > > If that's the case, why is there a contention for the "read" locks? > > Because you need an exclusive lock to create a read lock. > The exclusive lock is only held for a very short time (just > long enough to create the read lock), but it's still possible > for there to be contention for it. > > -Larry Jones > > I must have been delirious from having so much fun. -- Calvin > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
-D question
If I have a file in CVS that has a revision with a modification time of 2003-02-28 17:30:31 and I update my local working copy of the module that that file is in and I pass the -D argument with the value 2003-02-28 17:30:31, will that revision be included or will it be the one before it? So the question is, is the -D argument inclusive? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Really a reserved checkout?
Donald Sharp <[EMAIL PROTECTED]> writes: > The cvs documentation is obtuse and hard to read. It might be more useful to say that the documentation is designed as a reference - it will tell you everything there is to know about one aspect of CVS, then progress to another. This is useful if you already know how CVS works, but far less tractable a resource to actually learn CVS from. The same problem occurs with man pages on Unix; trying to learn Perl programming or shell scripting from their man pages, for example, is generally not possible without expending lots of imagination and time. The Python project solves this by having a wonderful and thorough Tutoral, as well as guides for different programming topics, that supplement the pure reference material in the Library Reference and Language Reference. The references are very useful once you know Python but it is really the Tutorial that gets you there. -- Brandon Craig Rhodes http://www.rhodesmill.org/brandon Georgia Tech[EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Really a reserved checkout?
The cvs documentation is obtuse and hard to read. I remember investing many days and hours understanding cvs. I imagine most people aren't interested in doing so. Having said that I don't think that the documentation is bad. It's very thourough, you just need to spend lots of time with it. People are just trying to get their jobs done. They want to treat a scm system as a black box, it's a rare developer who spends time to understand their tools. donald On Fri, Feb 28, 2003 at 04:13:05PM +, Mark Cooper wrote: > It still amazes me how many people are still unwilling to take the 'leap > of faith' to the 'concurrent' teamworking methodology which is, after all > what cvs is all about, and yet for some reason still want to use the tool. > I suppose it's analogous to riding a bycicle without stabilisers for the > first time. > > It leads me to wonder if there is something missing in the documentation > or the tool description from the (various) web site(s) that is somehow > preventing people from understanding what cvs is all about, although I > can't for the life of me see how anyone could 'miss' it. > > Perhaps I'm just too intolerant. > > Mark Cooper > > > > > > [EMAIL PROTECTED] (Larry Jones) > Sent by: [EMAIL PROTECTED] > 28/02/2003 15:33 > > > To: [EMAIL PROTECTED] (Arun Sundar) > cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject:Re: Really a reserved checkout? > > > Arun Sundar writes: > > > > Is this really possible in CVS. If I edit a file, UNTIL > > I COMMIT it no one should be able to commit that file. > > CVS is the *Concurrent* Versions System. If that's not what you want, > you're using the wrong tool. > > -Larry Jones > > Everybody's a slave to routine. -- Calvin > > > ___ > 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Lock contention executing cvs log
MacDonald, Ian writes: > > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="===91921517666352637==" Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! > Shouldn't cvs simply be using "read" locks while executing the log > command? It should, and it is. > If that's the case, why is there a contention for the "read" locks? Because you need an exclusive lock to create a read lock. The exclusive lock is only held for a very short time (just long enough to create the read lock), but it's still possible for there to be contention for it. -Larry Jones I must have been delirious from having so much fun. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Really a reserved checkout?
> It leads me to wonder if there is something missing in the documentation > or the tool description from the (various) web site(s) that is somehow > preventing people from understanding what cvs is all about, although I > can't for the life of me see how anyone could 'miss' it. I wrote this for my users. I know it's incomplete, but it may be of use to someone: http://www.zieg.com/faqs/cvs/#sect_merging ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Really a reserved checkout?
It still amazes me how many people are still unwilling to take the 'leap of faith' to the 'concurrent' teamworking methodology which is, after all what cvs is all about, and yet for some reason still want to use the tool. I suppose it's analogous to riding a bycicle without stabilisers for the first time. It leads me to wonder if there is something missing in the documentation or the tool description from the (various) web site(s) that is somehow preventing people from understanding what cvs is all about, although I can't for the life of me see how anyone could 'miss' it. Perhaps I'm just too intolerant. Mark Cooper [EMAIL PROTECTED] (Larry Jones) Sent by: [EMAIL PROTECTED] 28/02/2003 15:33 To: [EMAIL PROTECTED] (Arun Sundar) cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Really a reserved checkout? Arun Sundar writes: > > Is this really possible in CVS. If I edit a file, UNTIL > I COMMIT it no one should be able to commit that file. CVS is the *Concurrent* Versions System. If that's not what you want, you're using the wrong tool. -Larry Jones Everybody's a slave to routine. -- Calvin ___ 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
Re: Really a reserved checkout?
Arun Sundar writes: > > Is this really possible in CVS. If I edit a file, UNTIL > I COMMIT it no one should be able to commit that file. CVS is the *Concurrent* Versions System. If that's not what you want, you're using the wrong tool. -Larry Jones Everybody's a slave to routine. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Really a reserved checkout?
Folks, I am new to CVS. CVS gives the option of "reserved checkouts". www.wincvs.org offers a GUI where we have the option of 1.reserved edit 2.forced edit But the problem is even it is reserved edit/forced edit then the other person logs in alters the readonly file at the client and then commits it into the repository. In that case what does "exclusive locking" mean. Is this really possible in CVS. If I edit a file, UNTIL I COMMIT it no one should be able to commit that file. Thanks and Regards, Arun Sundar Arun Sundar - Analyst Programmer Global Software (India) Pvt.Ltd. 49,Venus Colony 2nd Street Alwarpet, Chennai 600 018 Phone: 91-44-2431 1061 (Office) Ext: 202 91-44-2618 0155 (Home) URL : http://go.to/arunsundar --- -/ --/ ---/http://www.geocities.com/delightfularun/index.html For further information about Global and its services please visit www.globalsw.com Confidentiality and Virus Statement The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This e-mail is not, and should not be deemed to be, a contract or any part of a contract. If you have received this e-mail in error please notify the sender. Whilst Global has taken every reasonable precaution to ensure that this e-mail and any attachments are free from any virus, we cannot accept liability for any damage which is sustained as a result of software viruses which may be contained in this email. We advise that in keeping with good computing practice the recipient should ensure that this e-mail and any attachments are actually virus free. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
