Re: cvs diff - new files
[ On Tuesday, June 17, 2003 at 11:24:26 (+0530), Jayashree wrote: ] > Subject: cvs diff - new files > > I've noticed that "cvs diff" does not show new files > when the export CVSROOT is not using pserver. > Any ways by which I can find out new files to be baselined > in a folder? How about trying "cvs diff -N"? > *** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *** This e-mail puts you on notice that I will not be bound by your confidentiality notice and will feel free to review, disclose, distribute, archive, laugh at, be amused by, poke fun publicly at, and/or publish anything I get in e-mail, either directly or indirectly, and whether intended for me or not, without any further notice. If you don't feel comfortable with that, I suggest that you not send any e-mail, especially not to me or any mailing list I might subscribe to; or at least that you use strong digital encryption to ensure that your e-mail can't be read by anyone other than its intended recipient. There are many ways to do this, including using such things as PGP, Lotus Notes, S/Mime, and many other similar systems. I apologize to you if it was not your decision to add this notice to your e-mail. However, given the number of places that have legalized shrink wrap licenses and the similarity of this license to same, I feel like it is incumbent on me to put you on notice immediately regarding my rejection of your notice. Please forward it to whoever in your legal department or management chain you deem as appropriate. EULA - [ All rights to the preceeding communication are fully retained by the author, the non-exclusive right to read and/or reproduce the preceeding text is hereby licensed to the public, subject to the following conditions: (a) Scope of Use: No person may read the preceeding text without first agreeing to be bound by these conditions. Reading, perusing, scanning or otherwise viewing or percieving the preceeding text whether by visual, auditory, olfactory, gustatory or tactile manner constitutes agreement to these terms. (b) Fair Use of Material: license is granted for fair use of the preceeding material, including but not limited to reproduction in whole or in part, quoted or unquoted, so long at that use does not annoy, offend, irk, distress, disturb, bother, harry or otherwise taunt, tease, belittle, libel, slander, critisize, contradict, dispute, demean or cause to be so the author of the preceeding work. (c) Limitation of No Offense: No person reading or otherwise consuming in any way such as (but not limited to) those methods described in part (a) is permitted to be offended, annoyed, irked, distressed, disturbed, bothered, or harried by the preceeding text. If the preceding text would do so, the license for it's use is pre-emptorily withdrawn and voided prior to it's reading. (d) Waiver of Recourse: the Licensee or Potential Licensee agrees prior to acceptance of this agreement to hold harmless and indemnify the author against any claim, civil or legal, which might arise from the perusal of the preceeding material. (e) Severability: The invalidation of any part of this license agreement shall in no way void the whole or affect the application of any other part of this agreement. (f) Sense of Humor: Any potential reader without a sense of humor is referred to parts (c) and (d) of this agreement and requested to note that the lack thereof is disqualified as mitigation of any of these terms. ] If you and/or your PHB still think your mailer should automatically attach a stupid disclaimer like this one to all your outgoing e-mail then please also read this: http://www.goldmark.org/jeff/stupid-disclaimers/> -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
update -j -j pulls in more than we want
Hello Lately I've been stung when applying update -j -j to wildly disparate versions of a program. CVS insists on pulling in unwanted fixes in order to meet its contextual needs it seems. While this makes sense is there any way of predicting or controlling how cvs behaves in such situations? regards Andrew * Disclaimer This email transmission is confidential and intended solely for the person or organization to whom it is addressed. If you are not the intended recipient, you must not copy, distribute or disseminate the information, or take any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of any organization or employer. If you have received this message in error, do not open any attachment but please notify the sender (above) deleting this message >from your system. Please rely on your own virus check no responsibility is taken by the sender for any damage arising out of any bug or virus infection. *___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
checkout/commit onto/from shared disks.
Hi, I'd like to start by thanking everyone for the advice I've received from previous posts...so thank you all. Alas, I once more seek your advice though. I intend to build a clustered linux solution for our developers to use. This would comprise of one central server upon which all the developers home directories and cvs server would reside. They will be logged into any one of many machines (nodes). My concern is being that each of our developers home directories will be a disk share from the central machine, and all the checkout/commit will be done via pserver onto these shares (I am considering using NFS to create the shares). If anyone can give me any guidance or foresight of any pit falls with such a mechanism, it would be gratefully appreciated. Thanks Dave B. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
what is your concern? The only one that I can see would be large files with frequent changes over a slow network. But even that wouldnt seem like much of an issue. Tom |-+-> | | "David Bowring" | | | <[EMAIL PROTECTED]> | | | Sent by: | | | info-cvs-bounces+thomas.maciejewski=us.socgen.| | | [EMAIL PROTECTED] | | | | | | | | | 06/17/2003 08:03 AM | | | | |-+-> >--| | | | To: <[EMAIL PROTECTED]> | | cc: | | Subject: checkout/commit onto/from shared disks. | >--| Hi, I'd like to start by thanking everyone for the advice I've received from previous posts...so thank you all. Alas, I once more seek your advice though. I intend to build a clustered linux solution for our developers to use. This would comprise of one central server upon which all the developers home directories and cvs server would reside. They will be logged into any one of many machines (nodes). My concern is being that each of our developers home directories will be a disk share from the central machine, and all the checkout/commit will be done via pserver onto these shares (I am considering using NFS to create the shares). If anyone can give me any guidance or foresight of any pit falls with such a mechanism, it would be gratefully appreciated. Thanks Dave B. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ** The information contained herein is confidential and is intended solely for the addresse(s). It shall not be construed as a recommendation to buy or sell any security. Any unauthorized access, use, reproduction, disclosure or dissemination is prohibited. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume any legal liability or responsibility for any incorrect, misleading or altered information contained herein. ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checkout/commit onto/from shared disks.
My concerns were merely that I had heard noises about using CVS on disk shares and was worried (in some part) about corruption, though I could not foresee it. All the clustered machines will be on a Gigabit backbone, so this should negate the network throughput issue. Cheers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 17 June 2003 13:10 To: David Bowring Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: checkout/commit onto/from shared disks. what is your concern? The only one that I can see would be large files with frequent changes over a slow network. But even that wouldnt seem like much of an issue. Tom |-+-> | | "David Bowring" | | | <[EMAIL PROTECTED]> | | | Sent by: | | | info-cvs-bounces+thomas.maciejewski=us.socgen.| | | [EMAIL PROTECTED] | | | | | | | | | 06/17/2003 08:03 AM | | | | |-+-> >--- ---| | | | To: <[EMAIL PROTECTED]> | | cc: | | Subject: checkout/commit onto/from shared disks. | >--- ---| Hi, I'd like to start by thanking everyone for the advice I've received from previous posts...so thank you all. Alas, I once more seek your advice though. I intend to build a clustered linux solution for our developers to use. This would comprise of one central server upon which all the developers home directories and cvs server would reside. They will be logged into any one of many machines (nodes). My concern is being that each of our developers home directories will be a disk share from the central machine, and all the checkout/commit will be done via pserver onto these shares (I am considering using NFS to create the shares). If anyone can give me any guidance or foresight of any pit falls with such a mechanism, it would be gratefully appreciated. Thanks Dave B. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ** The information contained herein is confidential and is intended solely for the addresse(s). It shall not be construed as a recommendation to buy or sell any security. Any unauthorized access, use, reproduction, disclosure or dissemination is prohibited. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume any legal liability or responsibility for any incorrect, misleading or altered information contained herein. ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
David Bowring wrote: > My concerns were merely that I had heard noises about using CVS on disk > shares and was worried (in some part) about corruption, though I could > not foresee it. All the clustered machines will be on a Gigabit > backbone, so this should negate the network throughput issue. AFAIK, the corruption issues relate to storing the repository itself on a network share. Max. > -Original Message- > From: [EMAIL PROTECTED] > > what is your concern? > The only one that I can see would be large files with frequent changes > over > a slow network. But even that wouldnt seem like much of an issue. > Tom > >> -+-> >> | "David Bowring" | >> | <[EMAIL PROTECTED]> | >> -+-> > > Hi, > > I'd like to start by thanking everyone for the advice I've received from > previous posts...so thank you all. > Alas, I once more seek your advice though. I intend to build a > clustered linux solution for our developers to use. > This would comprise of one central server upon which all the developers > home directories and cvs server would reside. They will be logged into > any one of many machines (nodes). My concern is being that each of our > developers home directories will be a disk share from the central > machine, and all the checkout/commit will be done via pserver onto these > shares (I am considering using NFS to create the shares). If anyone can > give me any guidance or foresight of any pit falls with such a > mechanism, it would be gratefully appreciated. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
Max Bowsher wrote: > > David Bowring wrote: > > My concerns were merely that I had heard noises about using CVS on disk > > shares and was worried (in some part) about corruption, though I could > > not foresee it. All the clustered machines will be on a Gigabit > > backbone, so this should negate the network throughput issue. > > AFAIK, the corruption issues relate to storing the repository itself on a > network share. As anecdotal evidence, I'd submit that I have been hosting several sandboxes on NFS shares for years without incident. As long as the path between the client and server is not over a network sharing system, you shouldn't have a problem. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
David Bowring writes: > > My concern is being that each of our > developers home directories will be a disk share from the central > machine, and all the checkout/commit will be done via pserver onto these > shares (I am considering using NFS to create the shares). If anyone can > give me any guidance or foresight of any pit falls with such a > mechanism, it would be gratefully appreciated. All of the known NFS problems are interoperability problems between different NFS implementations. Your proposed setup uses the same NFS implementation on all the machines, so it should work just fine. -Larry Jones I always have to help Dad establish the proper context. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
Riechers, Matthew W writes: > > As anecdotal evidence, I'd submit that I have been hosting several sandboxes > on NFS shares for years without incident. As long as the path between the > client and server is not over a network sharing system, you shouldn't have a > problem. NFS mounted working directories are just as problematic as NFS mounted repositories, it's just that the chances of having a problem are usually smaller (since the repository is more heavily used than a working directory) and the consequences of having a problem are less severe. If it works for you, then more power to you; I've been running an NFS mounted repository for years without incident, but I don't recommend it to others. -Larry Jones Apparently I was misinformed. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
[ On Tuesday, June 17, 2003 at 10:27:21 (-0400), Larry Jones wrote: ] > Subject: Re: checkout/commit onto/from shared disks. > > All of the known NFS problems are interoperability problems between > different NFS implementations. Well there can also be generic NFS problems between server and client of the same implementation. For example NetBSD has full support for file locking in the server, but none in the client. However for working directories there can be no more problems with NFS than there would be with any other ordinary file using application on NFS since there should never be more than one CVS process active in any given working directory at any time. -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
[ On Tuesday, June 17, 2003 at 13:03:52 (+0100), David Bowring wrote: ] > Subject: checkout/commit onto/from shared disks. > > This would comprise of one central server upon which all the developers > home directories and cvs server would reside. They will be logged into > any one of many machines (nodes). My concern is being that each of our > developers home directories will be a disk share from the central > machine, and all the checkout/commit will be done via pserver onto these > shares (I am considering using NFS to create the shares). If anyone can > give me any guidance or foresight of any pit falls with such a > mechanism, it would be gratefully appreciated. There is no problem with CVS sandboxes on NFS. However in such a scenario it would be not just unwise to use cvspserver, but unnecessary as well. Just use rsh! Rsh is FAR more secure than NFS. -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
Greg A. Woods writes [quoting me]: > > > > All of the known NFS problems are interoperability problems between > > different NFS implementations. > > Well there can also be generic NFS problems between server and client of > the same implementation. For example NetBSD has full support for file > locking in the server, but none in the client. Perhaps I should have said, "... problems with CVS ..." -- CVS doesn't use file locking. -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
This is more or less what I'm trying to set up, Checkout/commit over a small LAN here. Everything would be over shared drives, but I don't know how to setup the CVSServer, so if someone could point me to some documentation on this or any other help towards that end... The Repository would be on this machine which is Windows 98 (I should be able to come up with a more elegant setup in the future, but for now, I really just need this to work as it is.) With two other Windows machines accessing the repository. Anyway... Thanks in advance for any help... -Kristopher Hollingsworth --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: >[ On Tuesday, June 17, 2003 at 13:03:52 (+0100), David Bowring wrote: ] >> Subject: checkout/commit onto/from shared disks. >> >> This would comprise of one central server upon which all the developers >> home directories and cvs server would reside. They will be logged into >> any one of many machines (nodes). My concern is being that each of our >> developers home directories will be a disk share from the central >> machine, and all the checkout/commit will be done via pserver onto these >> shares (I am considering using NFS to create the shares). If anyone can >> give me any guidance or foresight of any pit falls with such a >> mechanism, it would be gratefully appreciated. > >There is no problem with CVS sandboxes on NFS. > >However in such a scenario it would be not just unwise to use >cvspserver, but unnecessary as well. Just use rsh! Rsh is FAR more >secure than NFS. > >-- > Greg A. Woods _ Free email at www.Z6.com ( and home of worldmap.com) _ Select your own custom email address for FREE! Get [EMAIL PROTECTED], No Ads, 6MB, IMAP, POP, SMTP & more! http://www.everyone.net/selectmail?campaign=tag ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
[ On Tuesday, June 17, 2003 at 11:38:41 (-0700), Kristopher Hollingsworth wrote: ] > Subject: Re: checkout/commit onto/from shared disks. > > This is more or less what I'm trying to set up, Checkout/commit over > a small LAN here. Everything would be over shared drives, but I > don't know how to setup the CVSServer, so if someone could point me > to some documentation on this or any other help towards that > end... The Repository would be on this machine which is Windows 98 > (I should be able to come up with a more elegant setup in the > future, but for now, I really just need this to work as it is.) With > two other Windows machines accessing the > repository. Anyway... Thanks in advance for any help... I think you're in the wrong newsgroup/mailing-list. As far as I know "this" CVS doesn't run as a server on M$-Windows-98. There is supposedly a version of CVS available for M$-NT, but it has its own user-support mailing list. In any case *I* would strongly recommend burning your Windoze install and putting something like FreeBSD, NetBSD, or Linux on your "server", or even some commercial UNIX System(TM). :-) -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
Yeh... That'd be nice, I'll see what I can't talk them in to doing... Oh well, Thanks for the help, it's appreciated. -Kristopher G. Hollingsworth --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > >I think you're in the wrong newsgroup/mailing-list. As far as I know >"this" CVS doesn't run as a server on M$-Windows-98. There is >supposedly a version of CVS available for M$-NT, but it has its own >user-support mailing list. > >In any case *I* would strongly recommend burning your Windoze install >and putting something like FreeBSD, NetBSD, or Linux on your "server", >or even some commercial UNIX System(TM). :-) > >-- > Greg A. Woods > >+1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> _ Free email at www.Z6.com ( and home of worldmap.com) _ Select your own custom email address for FREE! Get [EMAIL PROTECTED], No Ads, 6MB, IMAP, POP, SMTP & more! http://www.everyone.net/selectmail?campaign=tag ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checkout/commit onto/from shared disks.
Greg, I have recently rejoined the CVS community and have come to the conclusion that you are one of the most unhelpful people on the list. You sound like a throw back to 10 or more years ago when the "net" was free and attitudes like yours flourished. Bert -Original Message- From: Greg A. Woods [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 4:11 PM To: [EMAIL PROTECTED] Cc: CVS-II Discussion Mailing List Subject: Re: checkout/commit onto/from shared disks. [ On Tuesday, June 17, 2003 at 11:38:41 (-0700), Kristopher Hollingsworth wrote: ] > Subject: Re: checkout/commit onto/from shared disks. > > This is more or less what I'm trying to set up, Checkout/commit over > a small LAN here. Everything would be over shared drives, but I > don't know how to setup the CVSServer, so if someone could point me > to some documentation on this or any other help towards that > end... The Repository would be on this machine which is Windows 98 > (I should be able to come up with a more elegant setup in the > future, but for now, I really just need this to work as it is.) With > two other Windows machines accessing the > repository. Anyway... Thanks in advance for any help... I think you're in the wrong newsgroup/mailing-list. As far as I know "this" CVS doesn't run as a server on M$-Windows-98. There is supposedly a version of CVS available for M$-NT, but it has its own user-support mailing list. In any case *I* would strongly recommend burning your Windoze install and putting something like FreeBSD, NetBSD, or Linux on your "server", or even some commercial UNIX System(TM). :-) -- Greg A. Woods +1 416 218-0098;<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ 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
