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
