Re: CVS setup
Gurpreet Singh (SCM) writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! I just installed RH Linux 7.0 which had default CVS 1.10.8 While setting up CVS, I could not find the /etc/inetd.conf where we mention the access mode / cvsroot. I had being using /etc/inetd.conf earlier on Suse Linux 7.0. How and in which file I need to mention in RH 7.0 and 8.0. CVS 1.10.8 is pretty old, I suggest you upgrade to one of the current releases (1.11.6 is stable, 1.12.1 is experimental) that you can find at www.cvshome.org. You'll also find updated manuals that have setup instructions for xinetd (which is what you have) in addition to inetd. -Larry Jones It's hard to be religious when certain people are never incinerated by bolts of lightning. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Thanks Larry. Thank you very much. Works according to how I thought it should work. Regards, Rohit Peyyeti - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 29, 2002 9:28 PM Subject: Re: CVS setup help Rohit Peyyeti writes: Now, I am able to successfully login into CVS with CVS user called 'readroh'. But when I checkout files from the repository, I still get read+write file permissions and not as supposed to be read-only mode. A read-only user still gets read/write files, but they're not allowed to make any changes to the repository (e.g., they can't commit changes or set tags). Setting the $CVSREAD environment variable will give you read-only files, but won't (by itself) prevent you from changing the permissions, changing the files, and then committing them. Also, is 'readers' file created the same way as passwd file? No, the readers and writers files should be maintained with CVS. -Larry Jones See, it all makes sense. See? See?? They never see. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
This is the error which I get: (Logging in to readroh@server) CVS password: Fatal error, aborting. readroh: no such user cvs login: authorization failed: server servername rejected access As I know, I did not create any system user called 'readroh' but user called 'rohit' on the server which has my cvs-repository. ...Rohit - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: CVS Mailing Lists [EMAIL PROTECTED] Sent: Monday, January 28, 2002 1:25 PM Subject: Re: CVS setup help Rohit Peyyeti writes: rohit = system user readroh = cvs user I changed $CVSROOT/CVSROOT/passwd file. This is how it has right now: $CVSROOT/CVSROOT/passwd : readroh::rohit $CVSROOT/CVSROOT/readers : readroh In .bash_profile : CVSROOT=:pserver:rohit@server:/usr/local/cvs-rep There's the problem -- you're logging in as rohit. Change that to: CVSROOT=:pserver:readroh@server:/usr/local/cvs-rep -Larry Jones Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Rohit Peyyeti writes: (Logging in to readroh@server) CVS password: Fatal error, aborting. readroh: no such user cvs login: authorization failed: server servername rejected access Please do not summarize or truncate error messages when you report them -- there are a number of similar messages and that makes it impossible to tell exactly which one you are getting. Assuming your server is on a Unix-like system, there should be messages in your syslog that may help diagnose the problem. It would appear that CVS is either not reading your passwd file or is not interpreting it correctly. You are creating it, by hand, directly in the repository rather than trying to create it in a checked-out copy somewhere, right? Also, what version of CVS are you running? -Larry Jones I won't eat any cereal that doesn't turn the milk purple. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Sorry, forgot the version information: Concurrent Versions System (CVS) 1.10.8 (client/server) ...Rohit - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 10:13 PM Subject: Re: CVS setup help | Rohit Peyyeti writes: | | (Logging in to readroh@server) | CVS password: | Fatal error, aborting. | readroh: no such user | cvs login: authorization failed: server servername rejected access | | Please do not summarize or truncate error messages when you report them | -- there are a number of similar messages and that makes it impossible | to tell exactly which one you are getting. Assuming your server is on a | Unix-like system, there should be messages in your syslog that may help | diagnose the problem. It would appear that CVS is either not reading | your passwd file or is not interpreting it correctly. You are creating | it, by hand, directly in the repository rather than trying to create it | in a checked-out copy somewhere, right? Also, what version of CVS are | you running? | | -Larry Jones | | I won't eat any cereal that doesn't turn the milk purple. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Rohit Peyyeti writes: And I am not editing $CVSROOT/CVSROOT/passwd file directly in the repository directory. I first checkout the file and then edit it before committing. That's almost certainly your problem -- unless you've added passwd to the checkoutlist file, you don't actually have a $CVSROOT/CVSROOT/passwd file, you only have the corresponding RCS file ($CVSROOT/CVSROOT/passwd,v). Like the manual says, the passwd file is usually edited in place because there are serious security implications if you put it in CVS. Unless you understand what they are, I strongly advise that you *not* use CVS to manage the passwd file. Perhaps you should re-read the relevant section of the manual: http://www.cvshome.org/docs/manual/cvs_2.html#SEC29. -Larry Jones They can make me do it, but they can't make me do it with dignity. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Rohit Peyyeti writes: Concurrent Versions System (CVS) 1.10.8 (client/server) That's pretty old. If you upgrade to the current release (1.11.1p1), which you can get from www.cvshome.org, you'll get better error messages and a whole lot of bug fixes. -Larry Jones You're just trying to get RID of me, aren't you? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Hello Larry: Thanks for pointing this out. As of now, I did not add $CVSROOT/CVSROOT/passwd file to the checkoutlist file. I removed the old passwd file from the repository and created new passwd file under $CVSROOT/CVSROOT/ and tightened up direcoty permissions for $CVSROOT/CVSROOT. Now, I am able to successfully login into CVS with CVS user called 'readroh'. But when I checkout files from the repository, I still get read+write file permissions and not as supposed to be read-only mode. Also, is 'readers' file created the same way as passwd file? In either case it does not work. The readers file contains just one line: readroh. And for sure I gave new line at the end. Regards, Rohit Peyyeti - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 11:12 PM Subject: Re: CVS setup help Rohit Peyyeti writes: And I am not editing $CVSROOT/CVSROOT/passwd file directly in the repository directory. I first checkout the file and then edit it before committing. That's almost certainly your problem -- unless you've added passwd to the checkoutlist file, you don't actually have a $CVSROOT/CVSROOT/passwd file, you only have the corresponding RCS file ($CVSROOT/CVSROOT/passwd,v). Like the manual says, the passwd file is usually edited in place because there are serious security implications if you put it in CVS. Unless you understand what they are, I strongly advise that you *not* use CVS to manage the passwd file. Perhaps you should re-read the relevant section of the manual: http://www.cvshome.org/docs/manual/cvs_2.html#SEC29. -Larry Jones They can make me do it, but they can't make me do it with dignity. -- 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: CVS setup help
Larry: rohit = system user readroh = cvs user I changed $CVSROOT/CVSROOT/passwd file. This is how it has right now: $CVSROOT/CVSROOT/passwd : readroh::rohit $CVSROOT/CVSROOT/readers : readroh In .bash_profile : CVSROOT=:pserver:rohit@server:/usr/local/cvs-rep As usuall, I am logging to CVS by saying: 'cvs login' and enter by password. Then I say cvs checkout 'cvs checkout CVSROOT'. All the CVSROOT files come in read+write mode. ...Rohit - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 8:15 AM Subject: Re: CVS setup help Rohit Peyyeti writes: Thanks Larry, but I am having problems getting Read-Only access in CVS using pserver. I created user called 'rohit' in system and created respective entry in the CVSROOT/passed CVSROOT/readers. There is no CVSROOT/writers file. Here are the entries: CVSROOT/readers: - readroh CVSROOT/passwd: - rohit::readroh That's backwards -- that line says that the CVS user rohit should run as the system user readroh. Is there any special way for creating CVS user? Or just adding the entry in the passwd file enough without having to create another system user called 'readroh'? Simply adding them to the passwd file is sufficient, as long as you map them to a system user. When I checkout files after executing 'cvs login', I get all the files wiht rwx permissions. I can edit the files and commit them too, which should not be happening. Which user did you log in as, readroh or rohit? The readers file needs to list CVS users, not system users. You do have the readers and passwd files in $CVSROOT/CVSROOT and not just $CVSROOT don't you? -Larry Jones I think my cerebellum just fused. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Rohit Peyyeti writes: rohit = system user readroh = cvs user I changed $CVSROOT/CVSROOT/passwd file. This is how it has right now: $CVSROOT/CVSROOT/passwd : readroh::rohit $CVSROOT/CVSROOT/readers : readroh In .bash_profile : CVSROOT=:pserver:rohit@server:/usr/local/cvs-rep There's the problem -- you're logging in as rohit. Change that to: CVSROOT=:pserver:readroh@server:/usr/local/cvs-rep -Larry Jones Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup help
Rohit Peyyeti writes: Is there any better way to set this up? Also, I need read only access to certain project directories for some of the users. How is that possible? Set the permissions on the repository directories so that read-only users have read permission but not write permission. Read/write users should have both read and write permission. (Note that only directory permissions are important, not file permissions.) You'll also have to set LockDir= in your CVSROOT/config file to put the lock files somewhere other than in the repository since read-only users still need to be able to create lock files. I also tried setting up CVS in read-only mode by configuring CVSREAD environment variable. CVSREAD does *not* put CVS in read-only mode -- it just set the permissions on checked out files to read-only to prevent *accidental* modifications. -Larry Jones I don't NEED to compromise my principles, because they don't have the slightest bearing on what happens to me anyway. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
No, it is not. I think you need to figure out why the manager doesn't want to use concurrent development models especially if the advisory locks patch is installed to better control the process. Noel David Masterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Andrew writes: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Given the CVS model of unreserved checkouts, why do you need reserved checkouts? Also, are you talking about reserved checkouts of a file or an entire product? We use CVS (ver 1.11) and we like the unreserved checkout model, but the manager of a different project here wants to use our repository only if we can enforce reserved checkouts on a per-file basis (they don't want to use watches). Is it possible (and manageable) to make CVS do this? Greg Cooper ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
[EMAIL PROTECTED] (Kaz Kylheku) wrote: Tell the manager to shed his or her superstitions, and work with the facts. The facts are: - Concurrent development works just fine. - Your team already likes it. - Strict locking does not prevent concurrency, it only reduces it to a coarse granularity: coarse enough to interfere with productivity, but not coarse enough to eradicate conflicts. To eliminate conflicts, you have to lock the entire repository so that only one developer at a time can do anything on the software base as a whole. Well said. May I add, Concurrency works best with good communication among the developers. Responsibility of certain sections of code is usually divvied among just a few people. Strict locking might hurt the need for good communication among a group. Yes, exactly. The advisory locks patch (that I so eagerly advertise) is meant to increase communication among the developers, not to create true reserved locks (as the patch name implies -- I need to change this name). Noel 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Kaz Kylheku writes: [...with respect to CVS...] Tell the manager to shed his or her superstitions, and work with the facts. The facts are: - Concurrent development works just fine. - Your team already likes it. - Strict locking does not prevent concurrency, it only reduces it to a coarse granularity: coarse enough to interfere with productivity, but not coarse enough to eradicate conflicts. To eliminate conflicts, you have to lock the entire repository so that only one developer at a time can do anything on the software base as a whole. Since it is already working for you, you can invite the manager to witness, or participate in, some of your day to day version control activities. The point is that the development policy should fit the configuration management tool and the CM tool should fit the development policy. If the two don't get along, then the development environment is broken (well, if not broken, certainly very hampered). Brad Appleton's papers on SCM patterns provide a good start at understanding how to setup your policies and patterns: http://www.enteract.com/~bradapp/acme -- David Mastersondmaster AT synopsys DOT com Sr. RD Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
A huge portion of Streamed Lines deals with branches. Now, consider that unreserved checkouts are sort of like (if not exactly) virtual branches... IOW, if the manager is _really_ against concurrent development, then he/she should be against any version control tool that allows branches as well. OTOH, he/she may just want more control over the checkouts, in which case you may be able to sell him on the reserved checkouts patches (really more like advisory locks) available for CVS. Noel Kaz Kylheku writes: [...with respect to CVS...] Tell the manager to shed his or her superstitions, and work with the facts. The facts are: - Concurrent development works just fine. - Your team already likes it. - Strict locking does not prevent concurrency, it only reduces it to a coarse granularity: coarse enough to interfere with productivity, but not coarse enough to eradicate conflicts. To eliminate conflicts, you have to lock the entire repository so that only one developer at a time can do anything on the software base as a whole. Since it is already working for you, you can invite the manager to witness, or participate in, some of your day to day version control activities. The point is that the development policy should fit the configuration management tool and the CM tool should fit the development policy. If the two don't get along, then the development environment is broken (well, if not broken, certainly very hampered). Brad Appleton's papers on SCM patterns provide a good start at understanding how to setup your policies and patterns: http://www.enteract.com/~bradapp/acme -- David Mastersondmaster AT synopsys DOT com Sr. RD Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
David Masterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Andrew writes: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Given the CVS model of unreserved checkouts, why do you need reserved checkouts? Also, are you talking about reserved checkouts of a file or an entire product? We use CVS (ver 1.11) and we like the unreserved checkout model, but the manager of a different project here wants to use our repository only if we can enforce reserved checkouts on a per-file basis (they don't want to use watches). Is it possible (and manageable) to make CVS do this? Greg Cooper ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Greg Cooper wrote: David Masterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Andrew writes: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Given the CVS model of unreserved checkouts, why do you need reserved checkouts? Also, are you talking about reserved checkouts of a file or an entire product? We use CVS (ver 1.11) and we like the unreserved checkout model, but The what model? You seem to still be clinging to the biased terminology used by the vendors of inferior version control tools. ``Unreserved'' is a negative word that suggests risk and hassle, like an unreserved airplane ticket, restaurant table or hotel room. the manager of a different project here wants to use our repository only if we can enforce reserved checkouts on a per-file basis (they don't want to use watches). Is it possible (and manageable) to make CVS do this? Tell the manager to shed his or her superstitions, and work with the facts. The facts are: - Concurrent development works just fine. - Your team already likes it. - Strict locking does not prevent concurrency, it only reduces it to a coarse granularity: coarse enough to interfere with productivity, but not coarse enough to eradicate conflicts. To eliminate conflicts, you have to lock the entire repository so that only one developer at a time can do anything on the software base as a whole. Since it is already working for you, you can invite the manager to witness, or participate in, some of your day to day version control activities. -- . . . . . . - Mysterious Powdery Substance . ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
[EMAIL PROTECTED] (Kaz Kylheku) wrote: Tell the manager to shed his or her superstitions, and work with the facts. The facts are: - Concurrent development works just fine. - Your team already likes it. - Strict locking does not prevent concurrency, it only reduces it to a coarse granularity: coarse enough to interfere with productivity, but not coarse enough to eradicate conflicts. To eliminate conflicts, you have to lock the entire repository so that only one developer at a time can do anything on the software base as a whole. Well said. May I add, Concurrency works best with good communication among the developers. Responsibility of certain sections of code is usually divvied among just a few people. Strict locking might hurt the need for good communication among a group. -- David Gravereaux [EMAIL PROTECTED] $ make war make: *** No rule to make target `war'. Stop. Try `love' instead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Kaz Kylheku [EMAIL PROTECTED] wrote in message UClD7.130841$[EMAIL PROTECTED]">news:UClD7.130841$[EMAIL PROTECTED]... In article [EMAIL PROTECTED], Greg Cooper wrote: David Masterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Andrew writes: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Given the CVS model of unreserved checkouts, why do you need reserved checkouts? Also, are you talking about reserved checkouts of a file or an entire product? We use CVS (ver 1.11) and we like the unreserved checkout model, but The what model? You seem to still be clinging to the biased terminology used by the vendors of inferior version control tools. ``Unreserved'' is a negative word that suggests risk and hassle, like an unreserved airplane ticket, restaurant table or hotel room. I would add that instead of thinking of checkout you should think in terms of updates and commits. Before you start working on something, update your source. That way, you get the most recently committed changes. When you're done, you commit your changes. The key is to provide positive terminology that they can decide they like. The comments about granularity that I didn't quote are quite apropos. -K ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
How does one use the reserved locks? Jerzy Kaczorowski wrote: - Original Message - From: Paul Sander [EMAIL PROTECTED] There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. Noel Yap's patches have been succesfully applied into the cvsnt (www.cvsnt.org) long time ago and prove to work and be usefull. Jerzy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
I sent out instructions within the several threads about this. I guess you missed it 'cos you were too busy ranting. Please check the archives. Noel How does one use the reserved locks? Jerzy Kaczorowski wrote: - Original Message - From: Paul Sander [EMAIL PROTECTED] There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. Noel Yap's patches have been succesfully applied into the cvsnt (www.cvsnt.org) long time ago and prove to work and be usefull. Jerzy ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
- Original Message - From: Paul Sander [EMAIL PROTECTED] There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. Noel Yap's patches have been succesfully applied into the cvsnt (www.cvsnt.org) long time ago and prove to work and be usefull. Jerzy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Because there is no group, and there are no conflicts. This is just another Chicken Little yelling that the sky is falling. Actually a step beneath Chicken Little, because something actually did fall on Chicken Little's head, it wasn't just pure imagination. :) Yes, I was giving him the benefit of the doubt, but since he never did answer, What exactly are you doing that you're getting so many difficult-to-resolve conflicts?, I'm starting to believe he's one of those doom sayers you see in movies. Noel 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
I got the same impression David and Greg did. Method locking is something Envy in Visual Age has. Although I've never tried it myself, I think, at least for Java, it's fitting s square peg into a round hole since Java, by definition, is file based. Noel I think the original poster was referring to access controls on the primitive operations allowed on files by the version control system, e.g. some users are not permitted to commit on certain branches, others are not permitted to create tags, and so on. --- Forwarded mail from [EMAIL PROTECTED] [ On Friday, October 12, 2001 at 09:35:58 (-0500), Thornley, David wrote: ] Subject: RE: CVS - setup reserved checkout What do you mean by method locking? Locking individual parts of a file? It wouldn't do you any good. Well, not with CVS anyway! :-) Maybe in a multi-user smalltalk image it might (since you only ever edit one method at a time -- at least with the standard system browser), but smalltalkers have long ago decided that everyone needs to do merges all the time in order to share changes amongst their private images and that the best way to avoid conflicts is to never change an old method (unless it's just a fix), but rather to write a new one. There are problems with this process too, obviously (bloat and poorly integrated designs being the most common), but that's where refactoring steps in to save the day -- and it's really just a way to start over again with a whole new set of objects the same as you might start a whole new CVS module when beginning work on a major rewrite of some project. --- End of forwarded message from [EMAIL PROTECTED] ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
OK, then exactly what are you expecting from the link? Maybe SourceForge was down when you tried it? Have you tried it again? Have you tried following the step-by-step instructions I sent out? Noel I simply clicked on the link you supplied. I even copied it to IE just to make sure Nutscraper wasn't having a problem. [EMAIL PROTECTED] wrote: I was able to use Netscape get to the patches. Exactly what are you doing? Noel Netscape tries and tries, but nothing is ever returned by this link. Paul Sander wrote: Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 --- Forwarded mail from [EMAIL PROTECTED] Wo? Ich kann nicht es gefunden. Paul Sander wrote: There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] 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 Chase Co., its subsidiaries and affiliates. 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
-Original Message- From: Bryon Lape [mailto:[EMAIL PROTECTED]] Wrong. Kaz Kylheku wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: You need to ask yourself why your group is experiencing so many conflicts while so many other groups (thousands?) are not. Because there is no group, and there are no conflicts. This is just another Chicken Little yelling that the sky is falling. Actually a step beneath Chicken Little, because something actually did fall on Chicken Little's head, it wasn't just pure imagination. :) Gee, that's an informative response. You burst on the scene with complaints about a feature of CVS that has given none of us serious problems, and never explain why it is a problem for you. You never answer questions about what it is that you are doing, or make any significant responses to suggestions. The only way some of us have been able to interpret your complaints about CVS is that you have such a messed-up shop that no version control system is going to work, and that strict locking is merely going to shift the mess around a bit, and probably increase it. If you are here merely as a troll, then you're getting more consideration than you deserve. If you have a legitimate problem, then your problems are far more severe than any software product can handle, and free advice on mailing lists isn't going to help either. Right now, you're asking questions akin to When I use Amoco gasoline, my company's cars always catch fire. What additive should I use? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Kaz Kylheku wrote: CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. Conflicts are extremely easy to produce and may not be easily resolved. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Netscape tries and tries, but nothing is ever returned by this link. Paul Sander wrote: Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 >--- Forwarded mail from [EMAIL PROTECTED] >Wo? Ich kann nicht es gefunden. >Paul Sander wrote: >> There's Noel Yap's patches on SourceForge, which apply to a down-rev release >> of CVS. I believe that others have implemented it as well, but only privately >> in their own shops. Maybe they don't advertise them for fear of being blasted >> by Greg. >> >> --- Forwarded mail from [EMAIL PROTECTED] >> >> Paul Sander wrote: >> >> > If your question really is: "Is anyone modifying CVS to support locking?" >> > Then I believe the answer is "yes". >> >> Who? And where may I get it? >> >> --- End of forwarded message from [EMAIL PROTECTED] >--- End of forwarded message from [EMAIL PROTECTED]
Re: CVS - setup reserved checkout
It sounds like the software your group is maintaining needs factoring to decrease the likelihood that several developers are modifying the same method. It also sounds like your group can use some communication. Noel Greg A. Woods wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
--- Bryon Lape [EMAIL PROTECTED] wrote: Kaz Kylheku wrote: CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. Conflicts are extremely easy to produce and may not be easily resolved. The issue it seems you are having is that on a regular basis, two or more developers making large abouts of unrelated changes to same sections of code. This problem cannot be solved by locking checkouts, or by any change control tool. It doesn't matter whether you use checkout locking or not, merging will take place (the end result is the same, 2 developers apply 2 deltas to the same file). On the one hand 2 people can implement the changes at the same time then merge them. On the other hand 1 person can make changes while the other waits, then the other person can add (read merge in) his changes as he creates them. Developers that work on code must at least understand and communicate with each other, at the very least, with regards to the source code they jointly modify. How can one devloper make a change to filea and then a other developer modify the same code in filea, and not know how to merge the two changes in CVS? If the developer can't easily merge the changes, how can the developer easily add (read merge in) his changes to a file containing the 1st developers changes in a locking system? __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
If you've really made up your mind then don't use CVS. But think about this first: Why are you the only group I know who has tried parallel development and didn't like it? Noel *** REPLY SEPARATOR *** On 11/10/2001 at 23:03 [EMAIL PROTECTED] wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. I understand it, there aren't any. - Tired of NOT having your money backed by GOLD!?!? https://www.e-gold.com/newacct/newaccount.asp?cid=117395 Why settle for the low interest rates of banks? Why gamble in the stock market? http://www.emutualfun.org/m.cfm?mid=UPD886 ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Conflicts are extremely easy to produce and may not be easily resolved. The issue it seems you are having is that on a regular basis, two or more developers making large abouts of unrelated changes to same sections of code. This problem cannot be solved by locking checkouts, or by any change control tool. Yes, in fact, in environments I've been in that avoided unreserved checkouts at all costs, one developer started modifying a copy of the file that was locked. After the file was checked in, the developer checked the file out, copied his version over it, and checked it in thereby wiping out the other developer's changes. The moral: Developers will seek concurrent development even though they don't know how to do it properly. It's much better if the tool and procedures allow concurrent development. Noel 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
You need to ask yourself why your group is experiencing so many conflicts while so many other groups (thousands?) are not. Noel Kaz Kylheku wrote: CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. Conflicts are extremely easy to produce and may not be easily resolved. ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Conflicts are easy to produce *when you have multiple developers working on the same segments of code*. If you are doing a lot of that without any coordination between the developers, you are going to have a lot of problems. Period. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
-Original Message- From: Bryon Lape [mailto:[EMAIL PROTECTED]] The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. What do you mean by method locking? Locking individual parts of a file? It wouldn't do you any good. If you are getting large amounts of conflicts with CVS merging, that means that multiple people are changing the same parts of files in different ways. If the changes were localized in the files, so that different developers would be locking different member functions, then CVS would merge the changes just fine. In my experience, with some sort of locking developers waste time doing merging by hand. Developer A is adding a feature, and a bug report comes in from the field so developer B is assigned to fix it. B is now trying to hurry A up so she checks in and releases the lock, which means that A is likely to skimp on unimportant things like testing. Assuming B has not simply been playing 5,235 games of Minesweeper while waiting, B has likely figured out how to fix the bug, and then finds that A has modified that section and so he has to redo the bugfix. (Of course, if A did not modify that section, CVS would work just fine.) Alternatively, management yanks the lock away from A and gives it to B, who fixes the bug and checks in, and A now has to do the manual merging. Since merging of some sort is necessary when you have more than one person (or, in some cases, one person with more than one project) working on the same file, it's useful if the version control system actually has facilities to assist with the merge. Given that, it makes sense to allow concurrent development. You claim that the benefits are zero, in spite of the fact that many, many projects have found them to be great. It's pretty simple, really. If you have developers all over the place, changing everything in sight, then CVS isn't going to help you, but neither is anything else, because your shop is thoroughly messed up. If you have developers working on specific projects that change specific parts of the code, even if scattered among several files, then CVS is going to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
[ On Friday, October 12, 2001 at 11:22:37 (GMT), Bryon Lape wrote: ] Subject: Re: CVS - setup reserved checkout Conflicts are extremely easy to produce and may not be easily resolved. Hmmm. and how is this different from any other change control process? In non-parallel processes sometimes the conflicts are with locks and thus everyone but the lock holder must stop working. Even locking without lock contention won't solve all conflict scenarios. Commit wars are possible with any change control process. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
[ On Friday, October 12, 2001 at 09:35:58 (-0500), Thornley, David wrote: ] Subject: RE: CVS - setup reserved checkout What do you mean by method locking? Locking individual parts of a file? It wouldn't do you any good. Well, not with CVS anyway! :-) Maybe in a multi-user smalltalk image it might (since you only ever edit one method at a time -- at least with the standard system browser), but smalltalkers have long ago decided that everyone needs to do merges all the time in order to share changes amongst their private images and that the best way to avoid conflicts is to never change an old method (unless it's just a fix), but rather to write a new one. There are problems with this process too, obviously (bloat and poorly integrated designs being the most common), but that's where refactoring steps in to save the day -- and it's really just a way to start over again with a whole new set of objects the same as you might start a whole new CVS module when beginning work on a major rewrite of some project. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
Wow, Greg meets his match ... Bryon, Consider this: 3 developers (A,B,C) need to fix file X. A is making some major changes, adding lots of new functionality. B and C need to make a minor tweak to the file. In a CVS model: B anc C can be done and outa there in minutes and essentially forget about it. DONE. They are moving onto bigger and better things. X does an update and B and C's code is meged in automagically and there are no regressions. VERY COOL. In a lock while you work model. B and C need to wait for X to be done. This is very disruptive since B and C may need to work on somthing else big and their stuck waiting for X to finish or else they can change the code and potentially merge into X's code at some later time. There are issues with both models. Most people (including myself) feel that the issues relating to the CVS model are far fewer and less intrusive than the lock while you work model. I'm not saying you're wrong. However, I am saying I would find it very working with you on the same sources if you didn't choose CVS. There is a case where Greg would agree with you and that's in the case of binary files or files that can't be merged automagically - like jpegs or pngs. I STILL like the CVS model since in many cases these kinds of conflicts happen with process problems and not versioning problems - but that is a rEAlly long discussion that we don't need to get into. Good luck. G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Greg A. Woods Sent: Friday, October 12, 2001 9:14 AM To: [EMAIL PROTECTED] Cc: CVS-II Discussion Mailing List Subject: Re: CVS - setup reserved checkout [ On Friday, October 12, 2001 at 00:06:34 (-0400), Bryon Lape wrote: ] Subject: Re: CVS - setup reserved checkout *** REPLY SEPARATOR *** On 11/10/2001 at 23:03 [EMAIL PROTECTED] wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. I understand it, there aren't any. Sorry you feel that way -- many people. myself obviously included, find the parallel development paradigm almost invaluable. I happen to also like the way CVS forces it on its users, though many other less purposeful tools employ the same paradigm with less forcefulness (and many of them are very successful commercial tools -- people are choosing the parallel development paradigm with their pocket books too!). -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; 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
RE: CVS - setup reserved checkout
[ On Friday, October 12, 2001 at 09:51:54 (-0700), Gianni Mariani wrote: ] Subject: RE: CVS - setup reserved checkout There is a case where Greg would agree with you and that's in the case of binary files or files that can't be merged automagically - like jpegs or pngs. yes, of course! absolutely! I STILL like the CVS model since in many cases these kinds of conflicts happen with process problems and not versioning problems - but that is a rEAlly long discussion that we don't need to get into. indeed -- and your usage will undoubtably work out fine for you, especially if you don't use branches (in the modules with binaries) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Greg A. Woods wrote: Even locking without lock contention won't solve all conflict scenarios. Commit wars are possible with any change control process. Even if you lock an entire repository, you can still get conflicts; conflicts outside of the system. Suppose I have some wonderful plan to implement something, based on my current knowledge of the source code. I sit down to do it, but the repository is locked. Then when it is unlocked, I find that the code has changed in a way that makes it impractical to implement my idea in the same way. I now have to scrap or rework my idea, essentially performing a mental merge. If you exorcise merges from the version control system, you only push them elsewhere. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Bryon Lape wrote: Kaz Kylheku wrote: CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. Conflicts are extremely easy to produce and may not be easily resolved. Only in your FUD-filled imagination perhaps. In the very worst conflict scenario, you simply back out your changes, allowing the other developer's changes to supersede. You then lose your work. But that's work you would not have been able to carry out, had the other developer placed a strict lock! That is the full extent of the damage in the worst case conflict scenario; someone loses a bounded amount of work, which is a negative productivity hit. If it takes more work to do the merge than to scrap your work and redo it differently in the light of the new changes, then the only economically feasible alternative is to scrap your uncommited work! So there is an easy upper bound on the difficulty of conflict resolution. You are grossly exaggerating the risk by saying that these conflicts are ``extremely easy'' to produde. In reality, it has a very small probability of happening. If you multiply this vanishingly small probability by the negative amount of work done (work lost), you get some number that doesn't put so much as a dent in your overall productivity gain. Further, that risk is minimized by doing fine grained commits, frequent updates, and communicating with other developers. If you develop a feature for eight weeks without incorporating other modifications to your working copy, without breaking your work into finer-grained changes that are separately committed, and without talking to anyone, you may have a more difficult merge at the end. Heck, you might find that the whole project had been canceled seven weeks ago; now there's a conflict! Lastly, note that strict locking at the file level does not prevent conflicts, because parallel development can still take place on separate files. The project as a whole is being developed in parallel, and semantic conflicts can still arise. Full-blown parallel development without file locks is simply the realization that unless everyone places a big lock over the entire project for every single change, you are already doing parallel development. So why not just remove the final obstacle. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: RE: CVS - setup reserved checkout [ On Friday, October 12, 2001 at 09:35:58 (-0500), Thornley, David wrote: ] Subject: RE: CVS - setup reserved checkout What do you mean by method locking? Locking individual parts of a file? It wouldn't do you any good. Well, not with CVS anyway! :-) Maybe in a multi-user smalltalk image it might (since you only ever edit one method at a time I was apparently unclear; I meant that method locking would do no good for anybody who finds CVS unusable because of merge conflicts. If people can work on separate methods OK, then using CVS it really doesn't matter if they're parts of the same file or not, because the changes won't conflict. If, on the other hand, everybody is messing with widespread changes all the time, which is basically what you'd have to do to have that much trouble with CVS, method locking is no better than file locking, probably more likely to cause deadlocks, and certainly more of a pain to find who's using all the locks you need and why. If you *want* to use a locking version control system on files you edit in distinct segments, then I suppose locking by method is more suitable to your desires than locking by file. In that situation, though, there's no reason not to go concurrent. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
I got there by going to http://sourceforge.net/ and typing rcvs in the search field. That produced a table of about a dozen patches, one of which had a suitable one-description. I clicked on that, then on the download button. --- Forwarded mail from [EMAIL PROTECTED] Netscape tries and tries, but nothing is ever returned by this link. Paul Sander wrote: Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: You need to ask yourself why your group is experiencing so many conflicts while so many other groups (thousands?) are not. Because there is no group, and there are no conflicts. This is just another Chicken Little yelling that the sky is falling. Actually a step beneath Chicken Little, because something actually did fall on Chicken Little's head, it wasn't just pure imagination. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
One would hope that one's shop is not using the same branch for both maintenance and new features. That kind of thing is best done on separate branches (where the two schedules don't interfere with each other). The bug fix is later merged into the new development when it's appropriate to do so. Under those conditions, almost any version control tool provides the necessary merge tool. And locks don't matter because there's no concurrent development on the same branch. 'Course, it's a different story if multiple developers are adding their own bug fixes or features on either branch... --- Forwarded mail from [EMAIL PROTECTED] In my experience, with some sort of locking developers waste time doing merging by hand. Developer A is adding a feature, and a bug report comes in from the field so developer B is assigned to fix it. B is now trying to hurry A up so she checks in and releases the lock, which means that A is likely to skimp on unimportant things like testing. Assuming B has not simply been playing 5,235 games of Minesweeper while waiting, B has likely figured out how to fix the bug, and then finds that A has modified that section and so he has to redo the bugfix. (Of course, if A did not modify that section, CVS would work just fine.) Alternatively, management yanks the lock away from A and gives it to B, who fixes the bug and checks in, and A now has to do the manual merging. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
--- Forwarded mail from [EMAIL PROTECTED] [ On Friday, October 12, 2001 at 04:05:42 (GMT), Bryon Lape wrote: ] Subject: Re: CVS - setup reserved checkout The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. Obviously you've missed the point about how rare merging (automatic or by hand) is necessary in practice. Perhaps you should ask the developers participating in any of the large freeware projects using CVS just how often they waste any time doing merging tasks. I don't believe that merging is rare at all. In fact, I encourage merging often because many small merges are faster and easier than a few large ones. That's the key to the success of the concurrent development paradigm: Keep everyone close together in their workspaces without foisting other people's changes upon them in surprising ways. If you let people's workspaces diverge too far, then you fall into the same trap that is common with non-concurrent tools: The merges get big and cumbersome, to the point that the bulk of the effort goes into resolving conflicts rather than completing automatic or trivial (copy) merges. In the end, productivity is probably the same in either method. Developers spend a lot of time getting coffee every day while their automatic merges complete, or they slave away for hours resolving conflicts once every couple of weeks. But perception is everything here; letting the automation succeed is easier than thinking about interactions of conflicting code. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
--- Forwarded mail from [EMAIL PROTECTED] 3 developers (A,B,C) need to fix file X. A is making some major changes, adding lots of new functionality. B and C need to make a minor tweak to the file. In a CVS model: B anc C can be done and outa there in minutes and essentially forget about it. DONE. They are moving onto bigger and better things. X does an update and B and C's code is meged in automagically and there are no regressions. VERY COOL. In a lock while you work model. B and C need to wait for X to be done. This is very disruptive since B and C may need to work on somthing else big and their stuck waiting for X to finish or else they can change the code and potentially merge into X's code at some later time. Alternatively, X, B, and C could create their own branches, and require X to merge them when he's done. This is usually this kind of issue is resolved with a locking system. There are issues with both models. Most people (including myself) feel that the issues relating to the CVS model are far fewer and less intrusive than the lock while you work model. CVS makes people concentrate on different pieces of the puzzle. By allowing X, B, and C to share a branch, X is no longer required to remember to merge the bug fix branches when he's done with his changes. I'm not saying you're wrong. However, I am saying I would find it very working with you on the same sources if you didn't choose CVS. There is a case where Greg would agree with you and that's in the case of binary files or files that can't be merged automagically - like jpegs or pngs. I STILL like the CVS model since in many cases these kinds of conflicts happen with process problems and not versioning problems - but that is a rEAlly long discussion that we don't need to get into. I doubt that Greg would agree; he'd recommend (in his way) that such files be stored elsewhere. But files like jpegs and pngs can be managed with the concurrent paradigm if suitable merge tools are used. It's just that the one that CVS uses is not suitable for these types of files. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
I think the original poster was referring to access controls on the primitive operations allowed on files by the version control system, e.g. some users are not permitted to commit on certain branches, others are not permitted to create tags, and so on. --- Forwarded mail from [EMAIL PROTECTED] [ On Friday, October 12, 2001 at 09:35:58 (-0500), Thornley, David wrote: ] Subject: RE: CVS - setup reserved checkout What do you mean by method locking? Locking individual parts of a file? It wouldn't do you any good. Well, not with CVS anyway! :-) Maybe in a multi-user smalltalk image it might (since you only ever edit one method at a time -- at least with the standard system browser), but smalltalkers have long ago decided that everyone needs to do merges all the time in order to share changes amongst their private images and that the best way to avoid conflicts is to never change an old method (unless it's just a fix), but rather to write a new one. There are problems with this process too, obviously (bloat and poorly integrated designs being the most common), but that's where refactoring steps in to save the day -- and it's really just a way to start over again with a whole new set of objects the same as you might start a whole new CVS module when beginning work on a major rewrite of some project. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS - setup reserved checkout
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 1:34 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: CVS - setup reserved checkout One would hope that one's shop is not using the same branch for both maintenance and new features. That kind of thing is best done on separate branches (where the two schedules don't interfere with each other). The bug fix is later merged into the new development when it's appropriate to do so. The last job I had not involving the use of CVS was with SCCS, and we didn't have branches. This did make shipping bug-fixed stuff to customers interesting. Now assume the conditions where I'm working now, where the new features go on the main trunk and the bugfixes will be applied to a release branch, or maybe a patch subbranch. These need to be merged eventually, and I'd rather get them merged now before the developer forgets about them. Under those conditions, almost any version control tool provides the necessary merge tool. And locks don't matter because there's no concurrent development on the same branch. Any version control tool with branches. Of course, anything going in on the release branch probably should go into the development branch, and we're back to merging. The question, I suppose, is whether the merge will be done semi-automatically and promptly, so that the developer fixing the bug will watch it happen and have the problem fresh in his or her mind, or if it's going to be done manually and possibly at a later time, when the developer doesn't quite remember all the details, or not at all, and the developer finds a note three years later stuffed into documentation for an old version of the compiler about merging the change. I know which I prefer, but others seem to prefer cases 2 or 3. 'Course, it's a different story if multiple developers are adding their own bug fixes or features on either branch... Yup. Any time more than one developer is working on things at the same time, there's a need for merging. It is possible to design a locking protocol that obviates the need for merges or wasted work. When a developer has a project, he or she grabs all needed locks. If that developer cannot grab all of them, he or she releases the grabbed ones (to avoid deadlock, except in the case of race conditions. This can be avoided by giving each developer a different time of day to grab locks). If the developer has all locks necessary for a task, he or she works on that task. If the developer does not have all locks necessary for any assigned task, that developer surfs the web or plays bocce ball or something. Personally, I'm not convinced that this is better than having to merge. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Paul Sander wrote: Under those conditions, almost any version control tool provides the necessary merge tool. Your inexperience is showing. There are version control tools in *broad* use that have extremely support for branching and merging. Exhibit A: Visual SourceSafe. So it's not true that ``almost any version control tool'' provides the support. Only good ones. And locks don't matter because there's no concurrent development on the same branch. Two or more developers can do development on the same branch, because they are collaborating on the same feature. CVS supports such a concurrent programming use case, and it happens in practice. People are doing it around me as I write this. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Wrong. Kaz Kylheku wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: You need to ask yourself why your group is experiencing so many conflicts while so many other groups (thousands?) are not. Because there is no group, and there are no conflicts. This is just another Chicken Little yelling that the sky is falling. Actually a step beneath Chicken Little, because something actually did fall on Chicken Little's head, it wasn't just pure imagination. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
I simply clicked on the link you supplied. I even copied it to IE just to make sure Nutscraper wasn't having a problem. [EMAIL PROTECTED] wrote: I was able to use Netscape get to the patches. Exactly what are you doing? Noel Netscape tries and tries, but nothing is ever returned by this link. Paul Sander wrote: Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 >--- Forwarded mail from [EMAIL PROTECTED] >Wo? Ich kann nicht es gefunden. >Paul Sander wrote: >> There's Noel Yap's patches on SourceForge, which apply to a down-rev release >> of CVS. I believe that others have implemented it as well, but only privately >> in their own shops. Maybe they don't advertise them for fear of being blasted >> by Greg. >> >> --- Forwarded mail from [EMAIL PROTECTED] >> >> Paul Sander wrote: >> >> > If your question really is: "Is anyone modifying CVS to support locking?" >> > Then I believe the answer is "yes". >> >> Who? And where may I get it? >> >> --- End of forwarded message from [EMAIL PROTECTED] >--- End of forwarded message from [EMAIL PROTECTED] 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 Chase Co., its subsidiaries and affiliates.
Re: CVS - setup reserved checkout
Yeah, file locking is really unproductive. I just love wasting all that time tryin' to figure out why the merge didn't happen and do it all by hand. My boss really likes all the extra cost too. [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. Despite the outcry to have this capability, no one with commit access to the definitive sources seems to be taking it seriously enough to apply Noel's patch (or implement other things that have been discussed over the years), and no one seems to be writing something else that does locking and supplies CVS' other useful features. --- Forwarded mail from [EMAIL PROTECTED] The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
The patches are there for anyone to use. Last I heard, all that's stopping them from being included with the standard distribution are the lack of test and doc patches. You're welcome to work on them. Welcome to the world of open source. Noel The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ 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 Chase Co., its subsidiaries and affiliates. ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
No link to any files produces anything. One cannot download a patch that is not there. [EMAIL PROTECTED] wrote: The patches are there for anyone to use. Last I heard, all that's stopping them from being included with the standard distribution are the lack of test and doc patches. You're welcome to work on them. Welcome to the world of open source. Noel The RCVS part on source forge seems to be dead. Is anyone really developing locking for CVS? [EMAIL PROTECTED] wrote: The most you could hope for in CVS is to install a patch that allows advisory locks -- reserved locks are counter to the purpose of CVS. You can find a version of the patch (I think against cvs-1.11.1) at SourceForge under project RCVS. Once the patch is installed, tell the users that they must have cvs edit -c and cvs ci -c in their ~/.cvsrc files. Be sure to turn on notification as well. The process they should follow is: 1. When intending to modify a file for checkin, cvs edit the file. 2. If the files are being edited by others, contact the other parties to minimize the chances of conflicts. 3. If the chances of conflicts is minimal or the others cannot be contacted, cvs edit -f the files. 4. If one receives notification about an as-yet-unknown edit, contact the editor to help minimize the chances of conflicts. Noel Hello all, Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? If there is any info., please email to [EMAIL PROTECTED] Many thanks in advance Andrew ___ 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 Chase Co., its subsidiaries and affiliates. ___ 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame I think getting real reserved locks into CVS is impossible without chainging CVS so much as to make it not CVS anymore. Of course, you're welcome to try. Noel 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 Chase Co., its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
[ On Friday, October 12, 2001 at 02:17:41 (GMT), Bryon Lape wrote: ] Subject: Re: CVS - setup reserved checkout Paul Sander wrote: If your question really is: Is anyone making locking a mainstream feature of CVS? Then I believe the answer is no. shame Repeat after me: CVS == the _Concurrent_ Versions System Read the sub-title of Berliner's paper (included in the source). Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
*** REPLY SEPARATOR *** On 11/10/2001 at 23:03 [EMAIL PROTECTED] wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. I understand it, there aren't any. - Tired of NOT having your money backed by GOLD!?!? https://www.e-gold.com/newacct/newaccount.asp?cid=117395 Why settle for the low interest rates of banks? Why gamble in the stock market? http://www.emutualfun.org/m.cfm?mid=UPD886 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Wo? Ich kann nicht es gefunden. Paul Sander wrote: There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Greg A. Woods wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
In article [EMAIL PROTECTED], Bryon Lape wrote: Greg A. Woods wrote: Read Berliner's whole paper. Understand what it means to force developers to use a parallel development paradigm and learn what the benefits are. The benefits add up to zero. Now, if it did method locking, that would be helpful, protective AND productive. Without some sort of locking, having developers waste time with doing merging by hand is counterproductive. Nobody who actually has experience with parallel development could possibly say something so utterly clueless. Try it first, then talk. CVS doesn't require hand merging. When you perform a cvs update operation, then new changes in the repository are automatically incorporated into your working copy. Only when a conflict arises do you have to do resolution by hand. Conflicts tend to occur rarely, and are usually very easy to resolve. You will find that it takes less time to resolve the odd conflict than to wait for someone's lock to be released. So overall, productivity is boosted rather than reduced. Is there any hard, statistical data to back this up? No. But find someone who has done parallel development with reasonable tools, and who will testify that it was difficult or that it reduced productivity. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Ich funde es bei http://sourceforge.net/tracker/index.php?func=detailaid=422733group_id=4680atid=304680 --- Forwarded mail from [EMAIL PROTECTED] Wo? Ich kann nicht es gefunden. Paul Sander wrote: There's Noel Yap's patches on SourceForge, which apply to a down-rev release of CVS. I believe that others have implemented it as well, but only privately in their own shops. Maybe they don't advertise them for fear of being blasted by Greg. --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: If your question really is: Is anyone modifying CVS to support locking? Then I believe the answer is yes. Who? And where may I get it? --- End of forwarded message from [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
On Wed, Oct 10, 2001 at 01:18:55AM -0700, Andrew wrote: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Try http://cvsbook.red-bean.com/ for a very good book about CVS. Perhaps it clarifies things for you. If not, try to give a more specific description of the particular problem you have and we try to help you. Cheers, Matthias -- Matthias Kranz [EMAIL PROTECTED] http://www.buug.de/~mkr ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Andrew writes: Has anyone setup reserved checkout in CVS (ver 1.11.1p1) in Unix (Solaris)? Or is there any documentation on this other than the manual that comes with the source code? Given the CVS model of unreserved checkouts, why do you need reserved checkouts? Also, are you talking about reserved checkouts of a file or an entire product? -- David Mastersondmaster AT synopsys DOT com Sr. RD Engineer Synopsys, Inc. Software Engineering Sunnyvale, CA ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Setup Help Needed
Matt Keyes wrote: On the same note (but a little OT), how can I cut and paste from vi (I want to cut the encrypted password from /etc/passwd and put it in the cvspasswd file (whatever its called... I'm not at home so I can't look at it)? That depends on the interface or client you use to access the server with. If you want an easy way to manage the passwd and readers files though, try cvspwd 2 which can be found at http://www.pajamian.dhs.org Regards, Peter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Setup Help Needed
Matt Keyes writes: I'm running Slackware, I installed the latest CVS, and went through setting it up. I set up the port as per the docs, and configured inetd.conf with the following: cvs -f -allow-root=/cvsroot pserver /cvsroot is a partition I have that will be dedicated solely to cvs. However, its not working. I tried typing cvs-f -allow-root=/cvsroot pserver while logged in as root from the console, and it just sits there until I hit return or type something and hit return, then spits back the following message: cvs [pserver aborted]: bad auth protocol start: whatever I type before hitting return, or blank if I just hit return That's exactly what it should do. You're running it in server mode, so it expects to be talking to a client, not a person at a keyboard. Have you initialized your repository? Have you set $CVSROOT? Does it work in local mode? In short, do you have any idea at all what you're doing, or are you totally lost? Give us some more hints so we have some idea what to do to help you. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Setup Help Needed
Here's more info (and yes, I'm somewhat lost here...): 1. I set $CVSROOT to be /cvsroot 2. I did initialize the repository, so there is a /cvsroot/CVSROOT directory (with all the subdirectories under it that are created) 3. I haven't tried it in local mode... 4. I've been trying to connect via WinCVS, and I get the message equivalent to the one if you incorrectly type cvs (or just cvs) at a console prompt (not the whole usage message, just the first line). Sorry, I'm at work so I can't really get the message from here. Like I said, I'm somewhat lost simply b/c this is the first time I've tried to setup/use CVS. Thanks for any help! Matt -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, June 22, 2001 10:36 AM To: Matt Keyes Cc: [EMAIL PROTECTED] Subject: Re: CVS Setup Help Needed Matt Keyes writes: I'm running Slackware, I installed the latest CVS, and went through setting it up. I set up the port as per the docs, and configured inetd.conf with the following: cvs -f -allow-root=/cvsroot pserver /cvsroot is a partition I have that will be dedicated solely to cvs. However, its not working. I tried typing cvs-f -allow-root=/cvsroot pserver while logged in as root from the console, and it just sits there until I hit return or type something and hit return, then spits back the following message: cvs [pserver aborted]: bad auth protocol start: whatever I type before hitting return, or blank if I just hit return That's exactly what it should do. You're running it in server mode, so it expects to be talking to a client, not a person at a keyboard. Have you initialized your repository? Have you set $CVSROOT? Does it work in local mode? In short, do you have any idea at all what you're doing, or are you totally lost? Give us some more hints so we have some idea what to do to help you. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Setup Help Needed
Matt Keyes writes: 1. I set $CVSROOT to be /cvsroot That's not correct if you want to use pserver. You should set it to something like: :pserver:user@host:/cvsroot 2. I did initialize the repository, so there is a /cvsroot/CVSROOT directory (with all the subdirectories under it that are created) 3. I haven't tried it in local mode... Then how did you initialize the repository? :-) 4. I've been trying to connect via WinCVS, and I get the message equivalent to the one if you incorrectly type cvs (or just cvs) at a console prompt (not the whole usage message, just the first line). Sorry, I'm at work so I can't really get the message from here. I suggest getting pserver access working *on the server system* before trying to get it working remotely; it makes debugging much easier. For troubleshooting advice, see the manual: http://cvshome.org/docs/manual/cvs_21.html#SEC182 If you need more help, show us the exact error message and relavent line(s) from your inetd or xinetd configuration. -Larry Jones Hey! What's the matter? Can't you take a joke?! It was a JOKE! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS Setup Help Needed
Then how did you initialize the repository? :-) cvs -d /cvsroot init I suspect my main problem is with the $CVSROOT. Does the user in :pserver:user@host:/cvsroot need to be each username that will access the system? My /etc/services: cvspserver 2401/tcp My inetd.conf reads this: cvspserver stream tcp nowait root /usr/local/bin/cvs cvs -f -allow-root=/cvsroot pserver Like I said, I suspect that I need to set up the $CVSROOT correctly. Any more help is appreciated :)!!! Thanks! -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, June 22, 2001 12:47 PM To: Matt Keyes Cc: [EMAIL PROTECTED] Subject: Re: CVS Setup Help Needed Matt Keyes writes: 1. I set $CVSROOT to be /cvsroot That's not correct if you want to use pserver. You should set it to something like: :pserver:user@host:/cvsroot 2. I did initialize the repository, so there is a /cvsroot/CVSROOT directory (with all the subdirectories under it that are created) 3. I haven't tried it in local mode... Then how did you initialize the repository? :-) 4. I've been trying to connect via WinCVS, and I get the message equivalent to the one if you incorrectly type cvs (or just cvs) at a console prompt (not the whole usage message, just the first line). Sorry, I'm at work so I can't really get the message from here. I suggest getting pserver access working *on the server system* before trying to get it working remotely; it makes debugging much easier. For troubleshooting advice, see the manual: http://cvshome.org/docs/manual/cvs_21.html#SEC182 If you need more help, show us the exact error message and relavent line(s) from your inetd or xinetd configuration. -Larry Jones Hey! What's the matter? Can't you take a joke?! It was a JOKE! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Setup Help Needed
Matt Keyes writes: Then how did you initialize the repository? :-) cvs -d /cvsroot init Then you used CVS in local mode. That's why the smiley. I suspect my main problem is with the $CVSROOT. Does the user in :pserver:user@host:/cvsroot need to be each username that will access the system? Yes. (That is, each user sets it with their own username.) My /etc/services: cvspserver 2401/tcp My inetd.conf reads this: cvspserver stream tcp nowait root /usr/local/bin/cvs cvs -f -allow-root=/cvsroot pserver Those look fine (assuming it's really --allow-root). -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Setup Help Needed
I need more information to really be able to help but I'll give it a good shot. Did you do a cvs init? Verify that cvs commands work from the node where cvs is installed? The inetd.conf doesn't look correct. Mine looks like this: cvs stream tcp nowait root /opt/cvs/bin/cvs cvs -f --allow-root=/export/cvsroot pserver I initially did not use the -f and I lived to regret it. Sigh, it took me days to find that type-o. Have you set up the /etc/services file? See section 2.9.3 in the Cederqvist (http://cvshome.org/docs/manual/cvs.html) for help with the inetd and services files. WINcvs In WINcvs, you first need it to login successfully before you can do anything. Admin menu pick ... Login To interact with the repository: Create menu pick, General Tab fill is the first text field with the items in tailored to your site. :pserver:user@host:$CVSROOT for example, :pserver:jschwenk@pilot:/export/cvsroot I'm on the digest so feel free to email me directly. Good luck. Jeanie ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS setup
Hi, Have you tried importing the module with the dos command-line cvs client? this would force it to use the 8.3 dos names for all files and directories, (thus mangling the names to non-space for you.) All of our archives so far have been created initially in the Linux world so I have not tried this myself. Use a scratch monkey. Mike. -Original Message- From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: April 5, 2001 1:55 PM To: Rob Helmer Cc: M Birch; [EMAIL PROTECTED] Subject: Re: CVS setup Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ 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: CVS setup
(a bit late - sorry!) We manage many InstallShield sources in CVS without any problems. The only thing we try to do (but little goes wrong if we forget!) is to work on the Windows pieces by checking out to windows, and UNIX sources by checking out to UNIX. #!/mjh -Original Message- From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: 05 April 2001 18:55 To: Rob Helmer Cc: M Birch; [EMAIL PROTECTED] Subject: Re: CVS setup Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ 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: CVS setup
Ok, sorry I was so vague in my original message. By nothing but trouble I meant you have to be really careful about commitinfo scripts ( and the like ) and account for the fact that there may be spaces in the filename. It's bitten me in other ways, like when I want to grep or find in a sandbox ( or in the repository ) it doesn't always behave how I expect it to. It will work, however. It's just that dealing with spaces in filenames at all is a major PITA IMHO. Thanks, Rob Helmer On Wed, May 02, 2001 at 03:35:49PM +0100, Mark Hewitt wrote: (a bit late - sorry!) We manage many InstallShield sources in CVS without any problems. The only thing we try to do (but little goes wrong if we forget!) is to work on the Windows pieces by checking out to windows, and UNIX sources by checking out to UNIX. #!/mjh -Original Message- From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: 05 April 2001 18:55 To: Rob Helmer Cc: M Birch; [EMAIL PROTECTED] Subject: Re: CVS setup Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ 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: CVS setup
Hi David, I've been using CVS to control out install shield setups with spaces and all for a couple of years now and I've never experienced any problems. Just yesterday I created a bunch of modules with with spaces in their names and it seemed to work just fine, though I'm getting slightly worried by now :-/ regards /anders -Original Message- From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: 5. april 2001 19:55 To: Rob Helmer Cc: M Birch; [EMAIL PROTECTED] Subject: Re: CVS setup Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ 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: CVS setup
Anders Truelsen writes: I've been using CVS to control out install shield setups with spaces and all for a couple of years now and I've never experienced any problems. Just yesterday I created a bunch of modules with with spaces in their names and it seemed to work just fine, though I'm getting slightly worried by now :-/ Much (perhaps even most) of CVS is quite happy with spaces in filenames. Most of the problems are with interfaces to external scripts or things like the modules file. As long as you haven't had problems in the past, you probably won't have problems in the future. (Note that what you created were almost certainly top-level directories, not modules. Modules are only created by adding things to the CVSROOT/modules file and since that file is space delimited, it's not possible to create modules with spaces in their names.) -Larry Jones There's never enough time to do all the nothing you want. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS setup
Also worth mentioning in this thread is the fact that most of the files generated by InstallShield and the associated tool, Package for the Web, are ordinary text. Jerry ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Jerry Nairn wrote: Also worth mentioning in this thread is the fact that most of the files generated by InstallShield and the associated tool, Package for the Web, are ordinary text. Jerry Yes, that's what I was told, and that's one thing that makes me unwilling to zip everything up and store it in binary. I'd *much* rather store the text as text. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Jerry Nairn [EMAIL PROTECTED] writes: Also worth mentioning in this thread is the fact that most of the files generated by InstallShield and the associated tool, Package for the Web, are ordinary text. Yes, the unfortunate part is that InstallShield insists on using long names with embedded spaces for directories and files, which leads to odd inconveniences occasionally (eg, cvs -n update doesn't work properly, you can't use "find . -print | xargs ...", etc). ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Laine Stump writes: Yes, the unfortunate part is that InstallShield insists on using long names with embedded spaces for directories and files, which leads to odd inconveniences occasionally (eg, cvs -n update doesn't work properly, What goes wrong? you can't use "find . -print | xargs ...", etc). You can if you have the GNU versions of find and xargs: find . -print0 | xargs -0 ... (Actually, all you need is GNU xargs: find . -print | tr '\n' '\0' | xargs -0 ... although various versions of tr have slightly different syntaxes, so you might have to fool around a bit to get exactly the right incantation.) -Larry Jones We don't ATTEND parties, we just CRASH 'em. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
[EMAIL PROTECTED] (Larry Jones) writes: Laine Stump writes: Yes, the unfortunate part is that InstallShield insists on using long names with embedded spaces for directories and files, which leads to odd inconveniences occasionally (eg, cvs -n update doesn't work properly, What goes wrong? When I look at it more closely, I find: 1) It's not that big a deal. 2) it probably occurs when the directory names *don't* have spaces, too. (I just happened to notice it in a directory that had spaces in the name, and made a rash assumption). What I saw was a message like this: cvs update: New directory `ishield/Setup Files/Compressed Files/0009-English/Intel 32' -- ignored When the given directory is in the repository but empty (and I have -P in my .cvsrc, ie the directory doesn't exist in my workspace). When I do update without -n, no message about the empty directory is printed. It seems like "-n update" should notice that the directory is empty and -P is on, and print nothing. But, as I said, it's not a big deal. you can't use "find . -print | xargs ...", etc). You can if you have the GNU versions of find and xargs: find . -print0 | xargs -0 ... (Actually, all you need is GNU xargs: find . -print | tr '\n' '\0' | xargs -0 ... although various versions of tr have slightly different syntaxes, so you might have to fool around a bit to get exactly the right incantation.) Cool! Now that you say it, I think I remember seeing that before, but it didn't stick with me then because I didn't need it. After this, I promise I'll remember it! ;-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
On Fri, Apr 06, 2001 at 03:00:37PM -0400, Larry Jones wrote: You can if you have the GNU versions of find and xargs: find . -print0 | xargs -0 ... (Actually, all you need is GNU xargs: find . -print | tr '\n' '\0' | xargs -0 ... Well, GNU's find and xargs are distributed in the same package (findutils), so this shouldn't be too much of an issue :-) -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Eric Siegerman writes: On Fri, Apr 06, 2001 at 03:00:37PM -0400, Larry Jones wrote: (Actually, all you need is GNU xargs: find . -print | tr '\n' '\0' | xargs -0 ... Well, GNU's find and xargs are distributed in the same package (findutils), so this shouldn't be too much of an issue :-) True. The unstated benefit (which was perhaps a bit too subtle) is that it can be quite handy to do other line-oriented things (like grep, for example) between the find and the tr. -Larry Jones OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. Go into the repository and replace all the spaces with underscores ( _ ) or something, and do a fresh checkout. That should fix it. HTH, Rob Helmer Namodn On Thu, Apr 05, 2001 at 01:10:58PM -0400, M Birch wrote: I am having a problem after importing a 'module' into CVS which contained folder names that included a space. There's no problem until I started modifying the (modules) file to set up aliases to these directories. An example of a directory I have is under "Pages" there's another folder called "JSP Pages". I get an error any time I try and use the alias I setup to get to this directory. Is there anyway around this problem? I would appreciate any assistance with this matter. Mark The error message that is returned from the server is "cannot find module". I am using version 1.11 of CVS using a Linux machine as the server. ___ Do You Yahoo!? Get your free @yahoo.ca address at http://mail.yahoo.ca ___ 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: CVS setup
Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS setup
Hi David, Maybe you can use a commitinfo script to do this. I'm not really sure, I know people use them to strip CRs from files, I imagine you could automatically remove spaces like this somehow. Perhaps you could automatically convert them back on checkout. I'm not sure how this part would be done, but if you wanted to do such a thing I guess you would use a character that is unlikely ( or against procedure ) to have in any other checked-in file. If your CVS client can handle the spaces, you may be ok without this hackery. I know the CVS CLI doesn't deal well with them ( WinCVS uses a ported version of the UNIX CLI ). I'm not sure what other implications there are, maybe someone who's run into such situations could comment here. I'm not sure why you would check InstallShield files into CVS, but as you've clearly stated that you intend to use CVS, and intend to have spaces in the filenames, I hope this helps you somehow. -- Rob Helmer Namodn On Thu, Apr 05, 2001 at 12:54:43PM -0500, David H. Thornley wrote: Rob Helmer wrote: Don't check files or directories that have spaces in the names into CVS. It'll cause nothing but trouble. I was just asked a question about InstallShield. I'm not personally familiar with what it does, but apparently it creates a set of files of which many have spaces in their names, and it apparently cannot be set to do this as a matter of routine from pre-existing source. If there was an InstallShield script we could use, I'd say we keep the sources under CVS control and not worry about the InstallShield stuff. That apparently is not the case. There are too many filenames to make it practical to manually insert underscores instead of spaces. This being That Operating System, I don't know if it's easy to automate this process, like it would be in Unix. Not that this would be the ideal solution, since it would entail creating the files, mangling the names, checking them in, checking them out, unmangling the names, and sending to the user. I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. The half-assed solution we're adopting right now is to zip the files into a zip file without spaces in the file name, but there's plenty of reasons why this is suboptimal. Does anybody have any suggestions? There are reasons why we're using CVS, so I'd rather not hear why I should drop it in favor of something unspecified. Diatribes against proprietary Intel-based operating systems are unnecessary, unless they contain something amusing I haven't seen (or said) before. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/ ___ 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: CVS setup
My previous employer uses cvs and WinCVS with files with spaces in their names. cvs itself has only a couple of bugs, maybe even fixed in the latest release, with handling files with spaces in them. I remember that top level directories, and module names, should not have spaces in them. And you cannot check out a single file which has spaces in its name or its path, because no matter how you quote it, it gets broken at the space. I was able to set up log_accum.pl and cvsweb.cgi with minimal modifications to support filenames with spaces. All things considered, I think you're better off checking in the files with spaces in their names than checking in these zipped packages. Jerry From: David H. Thornley [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 10:55 AM I don't know if WinCVS handles this well. Nor do I know how it handles merging between branches, which in our setup depends partly on tag naming conventions, and therefore is not straight out-of-the-box CVS. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs setup for linux server,NT client
Hello Venu, how r things in Bangalore? To answer your question, You can use either WinCVS or CYGWIN tools on you NT box. Hereis how we have it implemented at our workplace: Our CVS products are setup to run using SSH or "Secure SHell," over TCP/IP.To use the Cygwin version of CVS...it basically boils down to this: 1) Download and install the Cygwin package ( http://www.cygnus.com/cygwin ). 2) As consistent with what we do around here, grab the whole directory tree "bin" under C:\cygnus\cygwin-b20\H-i586-cygwin32\bin (where c:\cygnus is the directory where you told Cygwin to install itself), and move it to C:\usr\local\bin. 3) Get an SSH client. http://www.wincvs.org/ssh.html discusses setup of the SSH client mentioning that one can be found at ftp://ftp.cs.hut.fi/pub/ssh/contrib 4) Cut and paste the following into a bat file (mine is called cvs_cmd.bat): set CYGWIN=tty set OPATH=%PATH% REM set PATH=c:\cygnus\cygwin-b20\H-i586-cygwin32\bin;c:\usr\local\bin;%PATH% set PATH=c:\usr\local\bin;%PATH% set CVS_RSH=c:/usr/local/bin/ssh1.exe set CVS_ROOT=cvs@foobar.yourdomain.com:/home/cvs/cvs set MAKE_MODE=unix start cmd set MAKE_MODE= set CVS_RSH= set CVS_ROOT= set CYGWIN= set PATH=%OPATH% 5) Running this bat should pop up a command window with all of the necessary environment variables set for using CVS. For a more in depth discussion of CVS and it's commands and operations, click the "CVS Manual" link below. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of VenuSent: Thursday, March 15, 2001 6:06 AMTo: [EMAIL PROTECTED]Subject: cvs setup for linux server,NT client Hi folks, I am very new to CVS,now we are implementing the CVS in LINUX server and NT for client system,i have querys to implmenting CVS.can anybody help me to do this How to set up linux (server) and windows NT (client),can i access by using Wincvs in NT to Linux server repositorys,is there any protocols should i use how to put this type of set up,is there any body done like this,could you pls tell me how to proceed. Thanks in advance, venu. B.Venu gopalSCM,Release Engineer#51,Stock Exchange Towers5th Floor,1st Cross,J.C RoadBangalore-560027[EMAIL PROTECTED]Ph:91 80 2995692
Re: cvs setup for linux server,NT client
I currently use RedHat Linux 6.2 as the CVS server, and multiple NT boxes as clients, so it sounds like your setup is very much like mine. If this mailing list is any indication, unless you are using RedHat Linux 7.0, CVS installation and setup should go quite smoothly. I had almost no trouble at all with CVS on Red Hat Linux 6.2, and I am anything but a unix expert. With a Linux/NT setup,you can choose just about any protocol you want -- there are no hard and fast rules for which ones to use. If you don't care about security, you can just use CVS's built-in"rsh" protocol (simple .rhosts setup,no external programs are required). If you want somesecurity but are not paranoid, you can use CVS's "pserver" protocol (simple inetd.conf setup, no external programs,but requires a password to logon). If you want lots of security, you can use "ssh"as an external protocol (I've never used SSH, but lots of other people have). Any of these protocolsshould work fine with your setup. The CVS manual discusses more about the different protocols and how to configurethem, which might also help you decide. I don't know anything about Cygwin, but WinCVSwill work with any of the above protocols. Hope this helps. - Dennis - Original Message - From: Venu To: [EMAIL PROTECTED] Sent: Thursday, March 15, 2001 6:06 AM Subject: cvs setup for linux server,NT client Hi folks, I am very new to CVS,now we are implementing the CVS in LINUX server and NT for client system,i have querys to implmenting CVS.can anybody help me to do this How to set up linux (server) and windows NT (client),can i access by using Wincvs in NT to Linux server repositorys,is there any protocols should i use how to put this type of set up,is there any body done like this,could you pls tell me how to proceed. Thanks in advance, venu. B.Venu gopalSCM,Release Engineer#51,Stock Exchange Towers5th Floor,1st Cross,J.C RoadBangalore-560027[EMAIL PROTECTED]Ph:91 80 2995692
Re: cvs setup help
Sounds like the path listed in etc/profile or in CVSROOT/modules may be pointing to the wrong place. Both need to point to the modules folder itself. For exact syntax, see: http://www.michael-amorose.com/cvs/ Michael C. Amorose Author FireUtils for Macintosh Author Sound Core for Macintosh Author Goo Library for Macintosh FireWire Watch Webmaster http://www.fireutils.com http://www.soundcore.com http://www.michael-amorose.com/goolibrary http://www.michael-amorose.com/firewire --- At 9:07 AM -0400 7/5/00, [EMAIL PROTECTED] wrote: Hi all, I'm new to this group, and have just started using CVS i think its a great program, and have been impressed with it. Everything has been working great with it until i tried setting another computer up, it worked fine the first time, except for one little mistake because they were binary files, so i just deleted everything, and ran the whole setup again, and then i had made the mistake of setting it up from my unix box, so instead of using the CVSROOT in the other computer it wanted to use mine, and since there was no access then it would just quit trying. So then i reran it again and now it doesn't work at all..does anyone know what the problem could be..?? please any help would be greatly appreciated. the problem is occurring when trying to checkout a working copy, i get this error cvs checkout: cannot find module "Testfile" - ignored thanxs.. Jorge
Re: cvs setup help
On Wed, Jul 05, 2000 at 09:07:55AM -0400, [EMAIL PROTECTED] wrote: I'm new to this group, and have just started using CVS i think its a great program, and have been impressed with it. Everything has been working great with it until i tried setting another computer up, it worked fine the first time, except for one little mistake because they were binary files, so i just deleted everything, and ran the whole setup again, and then i had made the mistake of setting it up from my unix box, so instead of using the CVSROOT in the other computer it wanted to use mine, and since there was no access then it would just quit trying. So then i reran it again and now it doesn't work at all..does anyone know what the problem could be..?? please any help would be greatly appreciated. the problem is occurring when trying to checkout a working copy, i get this error cvs checkout: cannot find module "Testfile" - ignored It is somehow confusing to me ... :). Please provide us the exact value of echo $CVSROOT and/or the commands you are using. Regards, Matthias -- Matthias Kranz [EMAIL PROTECTED] http://www.belug.org/~kranz "Ever tried. Ever failed. No matter. Try again. Fail again. Fail better." (Samuel Beckett)
