Re: Remove user as watcher/editor completely
I think you've pretty much listed all your options, however, note that modifying the CVS/fileattr files can be automated making it not-so-tedious. Noel A developer has left our company. I deleted his account and all that. But he is still mentioned hundreds' of times as editor and/or watcher of files in our CVS repository. Is there a way to remove all hist wathes and all his cvs edit commands with just a single command? The cvs watch remove command has no option to remove all watches of a certain user. Note that I cannot login as the user since I already deleted his account (unless I recreate it). The only solution I have so far is to manually edit the CVS/fileattr files in every directory. It is a tedious task... Any hints are welcome! Thanks, Hans Drexler [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: Remove user as watcher/editor completely
Oh, I forgot, there's a patch against cvs-1.11 available at SourceForge under project RCVS that'll add a -e editor option to cvs unedit. If the user hasn't done cvs watch (eg only cvs edit), this patch may help. I still think, though, that the easiest thing to do is modify the CVS/fileattr files. Noel A developer has left our company. I deleted his account and all that. But he is still mentioned hundreds' of times as editor and/or watcher of files in our CVS repository. Is there a way to remove all hist wathes and all his cvs edit commands with just a single command? The cvs watch remove command has no option to remove all watches of a certain user. Note that I cannot login as the user since I already deleted his account (unless I recreate it). The only solution I have so far is to manually edit the CVS/fileattr files in every directory. It is a tedious task... Any hints are welcome! Thanks, Hans Drexler [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
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
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
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
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 edit -c command
I got the link through clicking. I think you're doing something wrong. Can you explain all the steps you're taking? Better yet, I'll tell you how I got to the patches: 1. User your browser to go to http://www.sourceforge.com/ 2. Enter RCVS into the search field 3. Click on Renegade CVS 4. Click on Patches 5. Click on enh: reservations 6. Scroll down 7. Click on Download Noel PS DOA stands for Dead on Arrival (the arrival of the thing that's DOA, that is). I think you're misusing the term since RCVS may be dead now, but it wasn't dead when it started. blape@grey-neTo: [EMAIL PROTECTED] t.comcc: Sent by: Subject: Re: cvs edit -c command info-cvs-admi [EMAIL PROTECTED] 10/11/2001 10:21 PM Sure, if you have the link already. This one produces nothing: http://sourceforge.net/project/showfiles.php?group_id=4680 This one produces cvs commands that do not work (no log in allowed): http://sourceforge.net/cvs/?group_id=4680 The ftp link is to a directory that does not exist. I stand by what I wrote. This project is unreachable and DOA. [EMAIL PROTECTED] wrote: I don't know what you're talking about. I was able to get the reservations patch at http://sourceforge.net/tracker/download.php?group_id=4680atid=304680file_id=6141aid=422725 Noel There are no files to download in this project. Looks DOA. [EMAIL PROTECTED] wrote: The patch is available at SourceForge under project RCVS. The gist of the patch is: 1. cvs edit -c will abort the edit if another is editing the files. 2. cvs edit -f will force the edit. 3. cvs ci -c will abort the checkin if a valid edit does not exist on the files. Noel Does anyone know where I can find some info on this command and arguments. I can't seem to find it Thanks Curt Stanton ___ 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. This communication is for informational purposes only. It is not intended as an offer or solicitation for the
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
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: Making a file writeable
Then spend time doing the merge by hand and having to possibly to ahold of the programmer who made other changes to make sure everything is done correctly. Now two programmers, at least, are being unproductive and costs are going up. Don't you have regression tests to check if you've broken something? Noel James Knowles wrote: In a sane and normal source control system, Do you mean a we can't figure out how to implement parallel development so we'll put a straightjacket on our customers and convince them that it's superior source control system? files stay read only until you check them out. Bad Bad Bad Bad Bad Oh how many times I've wanted to smack somebody up side the head for this. This is OK only in some development environments. CVS seems to be neither and lets people change files at will. This is quite bad and counter productive. Have you attempted to understand the theory of operation? I've spent a weekend giving myself a crash course in CVS. Yes, it's different than, say Visual Source Safe, but it's neither wrong, bad, nor counterproductive. I rather like it. Sadly it's freaking another developer out in a big way -- and I have to deal with him. CVS requires a mental adjustment to client-oriented parallel development. The straightjacket is off. I guess it's like freedom. Freedom scares the living daylights out of people conditioned to living under tight controls. -- Practice makes permanent. Perfect practice makes perfect. - Seville ___ 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
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 edit -c command
I don't know what you're talking about. I was able to get the reservations patch at http://sourceforge.net/tracker/download.php?group_id=4680atid=304680file_id=6141aid=422725 Noel There are no files to download in this project. Looks DOA. [EMAIL PROTECTED] wrote: The patch is available at SourceForge under project RCVS. The gist of the patch is: 1. cvs edit -c will abort the edit if another is editing the files. 2. cvs edit -f will force the edit. 3. cvs ci -c will abort the checkin if a valid edit does not exist on the files. Noel Does anyone know where I can find some info on this command and arguments. I can't seem to find it Thanks Curt Stanton ___ 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: Edit, Editors, and Branches
IIRC, edit keeps track of edits on a per file basis. I think many things would have to change for it to track edits sn a per branch basis (eg What if the branch gets redefined? Some users would care about other branches. There might be others.) Noel I seem to have encountered an oddity in CVS and I'm not sure whether this was an oversight on the part of CVS, or me :) ? Let's assume that you have a file foo.c, with a branch of Branch1. Now, say that a user has foo.c checked out in their workspace on Branch1 (cvs update -r Branch1 foo.c) and then edits it (cvs edit foo.c). Have a second user get the mainline version of foo.c (cvs update -A foo.c), and then runs the Editors list on it (cvs editors foo.c). Now does it make sense that the second user will see the 'edit' status of the first user even though the first user did the edit on the branch, and not on the mainline? 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 access control
I starting to think the best security doesn't base or rely on security through obscurity. However, obscurity can strengthen security to an extent. For example, how many of us are able to obtain Air Force One's flight path at any given moment? Security is strengthened when the enemy doesn't know the terrain as well as we do. Noel [[EMAIL PROTECTED] - Mon at 10:17:40AM -0400] I've actually questioned one bank and they said it's against policy to disclose any of the details. They all do - which strengthens the theory that they really base their security by obscurity. -- Unemployed hacker Will program for food! http://ccs.custompublish.com/ 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: How to use CVSup and edits/watches?
3. A user would need to wait till the datalink is up before being able to 'cvs watch' or 'cvs edit' a file. The user would need to keep manual records of which files need to be watched or edited once the datalink becomes available. I think CVS buffers this information until the link is back up. The next time the user uses CVS and the link is up, CVS will send the watch and edit info over. 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 access control
Still, it seems like a lot of banks actually can afford to lean on security by obscurity. That's because they're in a position of authority and their customers do not question their declarations (often because of course they do not have the expertise to do so, especially in technologically related matters). I've actually questioned one bank and they said it's against policy to disclose any of the details. OTOH, my company was happy to let me know how our dial-in security worked (I'm not sure if they would've done the same for our customers, though). 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 access control
The only secure banking system I've seen used such a device for creating one-time codes, but it wouldn't rely on a session, it would require the user to enter the code for _each_ transaction that was to be performed. That's quite secure. But then again, what's the point, when the calculator and the PIN is sent by regular mail service? Anybody snooping by my the mailbox every day before I get to it might easily steal both the generator and the PIN. IMHO, key distribution is the hardest part in the security system to strengthen (even SSH can be used with a weak distribution mechanism). Since anyone who wants to subvert the key distribution must always watch the distribution mechanism, I think it's harder to break than a system that distributes the key all the time. I can hardly argue that any of those things are important. Not for me, at least. I can't tell for others. I'm not sure ACLs on branches are meaningful at all to anyone, at least not in the bigger picture. Well, at least I've been in a situation where it could be meaningful - we wanted a lot of independent developers to have the right to commit to an experimental branch, while the stable branch only should be touched by some highly trusted person. Thus we could recommend anyone to use the stable branch. Like I said before, this should be done by extending commitinfo to pass branch info to the commitinfo scripts. 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 access control
Yes - love the idea of pserver keeping usernames / passwords independant of the OS, and keeping cvs running as non-root. I'm not sure if this is possible since I haven't tried it out myself, but I think you can have each user have their own SSH keypair into a shared account on the CVS server. SSH can be configured so that all they can execute is cvs and, IIRC, the environment variable CVS_USER can be set on a per-key basis so that cvs records the proper username. 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: As if there wasn't enough discussion about access control...
Read only users need write permissions into the directories where locks are created (see LockDir configuration). They also need read permissions to the repository directories and archives. Noel jrimmer@ellipsisdTo: [EMAIL PROTECTED] igital.com cc: Sent by: Subject: As if there wasn't enough discussion about access control... info-cvs-admin@gn u.org 09/27/01 02:05 PM I've set up CVS on a Linux server. We access it over SSH. Currently, access is through group permissions; if you're a member of the 'cvs' group on the Linux box, you have full access the repository. But if you're not... I'd like to be able to establish some sort of checkout-only access for the folks in marketing. Is there a way to create such a thing using Unix file permissions? Or do I need to dig into the administrative files? - Jimmy Rimmer, [EMAIL PROTECTED] http://mp3.com/Rimbo?edSig - ``Are all men from Texas loud-mouthed braggarts?'' ``Just me, baby. Just me.'' ___ 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 access control
Still - security through obscurity /is/ better than no security at all! Nope, not true at all. Security by obscurity leads to a false sense of security, and as pretty well every rational sane person in North America should realise by now there's really nothing worse than a false sense of security! Extremely well said! 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 access control
[ On Wednesday, September 26, 2001 at 17:01:25 (-0400), [EMAIL PROTECTED] wrote: ] Subject: Re: CVS access control By definition, security is about preventing malicious users from doing harm. It's not about avoiding accidents by careless users. For example, would you consider a knotted rope tying my door shut to be any sort of security since it avoids accidental openings? This I must pick a nit with. :-) One of the three corner-stones of security is integrity. Good security not only prevents malicious damage, but also accidental damage. OK, but I wouldn't consider secure a system that only prevents accidental damage. 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: File permissions
The problem is that, among a lot of public files (mode 644), there is some few secret files (mode 600). cvs add will silently ignore any file permissions and make the ,v-file world readable (mode 444). I can think of four solutions to the problem: 1. Keep files that need to be available to the public and files that should be kept secret in separate repositories, and restrict read/execute permissions to the secret $CVSROOT. Works well for my case, anyway - but certainly not recommended if there are both public and secret files in the same directory. It's not a good idea to keep public and private files in the same directory anyway since the directory permissions play a major role in this. For example, if write permissions were set for the directory, any of the private files can be removed. 2. Keep the secret files away from the CVS repository, they don't belong there anyway. It depends. 3. Add and commit an empty file with the same filename as the secret file, and set the right permissions at the ,v-file before committing the real secret file. I can certainly do that, but I don't expect just any cvs user to do the same. Again, it's the directory permissions that's important. 4. Hack cvs, so that it automaticly creates new ,v-files respecting the restricted mode of the original file if some command line option is given. Eventually let cvs warn if it makes a repository file that is more readable than the work file. You've done more work and you still have the directory permissions to contend with. It is the last point I really want comments on - is it a smart thing to do, or not? If you really want to keep these files private, keep them in a separate repository. At the very least, keep them in a separate directory and manage all the permissions extremely carefully. I think it's much easier and safer to keep them in a separate repository since the permissions are easier to manage. 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 access control
Personally, I'm against the idea that CVS implement its own directory-level ACLs -- this is a file system issue. If one were to be developed, though, the interface (eg set and get ACLs) should default to using file system ACLs if available. If file system ACLs aren't available, I would prefer this information be kept within the CVS subdirectory of the repository (as a side issue, I think the location of the CVS subdirectory should be configurable just like LockDir). Also, the ACLs should stick to standard permission semantics. Noel To meet the needs of a large repository with numerous users, I've been playing with adding directory level access control to CVS. (The repository is hosted on a server which does not have native ACL support in the file system and I don't want to give the casual administrator shell access to the server anyhow). It works as follows; A client starts CVS on the server and just after the server checks to see if the command being issued is allowed by checking CVSROOT/readers and CVSROOT/writers, it then looks for the file CVSROOT/access/%username%. The access file contains a simple rule chain for determining access to directories. In the guts of CVS (recurse.c) where it does all the heavy lifting, it checks each directory that is entered to see if the user has the necessary access. If the user does not have access then it's as if the directory doesn't exist. The access files have the following format: READ|WRITE DIRECTORY REGEXP A typical file could look like this: READ ^Readable WRITE ^Writable READ ^Read/Access/But/Not/Below/Here$ WRITE ^Write/Access/But/Not/Below/Here$ When the file is loaded it is parsed in READ or WRITE context based on the command being issued (much like the tests against CVSROOT/readers and CVSROOT/writers). If the command requires READ access then the rules which grant READ or WRITE access are considered. If the command requires WRITE access then the rules which grant READ access are ignored. If the access file exists for a user then all directories in the repository which don't match any of the rules are considered as NO ACCESS. Anyhow, the reason I'm posting is to get your feedback on such a scheme. Matt. ___ 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 access control
When you're at it, you should also allow for different ruling on different branches, not only directories. I've been into the need for having write-permission (and it's a nice idea in general) only to the a particular sandbox branch of a project. That would be a nice feature in CVS, also because it _can't_ be supported only on the basis of file permissions. I'm kind of against this, too, since branch-level permissions don't afford security at all since the archive file is still writable. All these ACLs will afford is a false sense of security. The right way to do what you want (although I'll admit it's more difficult) is to create a file system that supports versioning. katie (http://www.netcraft.com.au/geoffrey/katie/) is such a project but I don't know how it's progressing. 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 access control
[[EMAIL PROTECTED] - Wed at 10:45:50AM -0400] I'm kind of against this, too, since branch-level permissions don't afford security at all since the archive file is still writable. The pserver method is, as for now, the only one that can offer any real access controls. As I understood, cvs users could only access the box in question through cvs. I see nothing wrong with SSH. Also, from what I've heard, pserver is not secure. cvs.SourceForge.org has also solved this problem somehow; people logging in (through ssh) are only allowed to use cvs. Exactly, SSH affords better security than pserver. Another option is setuid'ness. CVS is not currently constructed for it, anyway it can be considered. I've tried this (on an experimental basis) and had no problems whatsoever. But then, how do you control who is able to execute this setgid (I wouldn't use setuid) cvs? I used file system ACLs. ACL is a bit on the edge, but it could certainly be considered to be within the scope of an advanced version control system. A paranoid system manager certainly would not give write permission on the ,v-files to ordinary users. They should only be operated through cvs. I don't think ACLs in this respect should be within the domain of the version control tool. I think you don't fully understand how CVS treats file system permissions. Although permissions on ,v files play some role, the permissions on the directories are way more important. The reason is that a new ,v file is created each time the file is checked in. I think the permissions on the new archive file is controlled by the users' umask. The right way to do what you want (although I'll admit it's more difficult) is to create a file system that supports versioning. I wouldn't go there. Logging transactions (thus offering a rollback possibility to any given timestamp), just like for a database, could be within the scope of a file system. Complex version control, like cvs offers, is IMHO a bit out of file system scope. Or maybe not? Hm! ClearCase is one example of versioning through the file system. 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 access control
[[EMAIL PROTECTED] - Wed at 01:23:12PM -0400] The pserver method is, as for now, the only one that can offer any real access controls. As I understood, cvs users could only access the box in question through cvs. I see nothing wrong with SSH. Also, from what I've heard, pserver is not secure. I think we're miscommunicating a bit. If we rely on the file system for all the access control, SSH is perfect! I think you're confusing authorization with authentication. SSH is perfect for authentication. It does not do authorization (short of minimally controlling what set of commands you're allowed to execute). The original poster had a need for _additional_ access control. I can see three quite so good reasons why it might be needed: 1. As the original posters problem: Because it was not given by the OS (what a crappy OS!). Then get a file system that's POSIX compliant. An alternative is to have multiple groups and manage the permissions within the repo. 2. A user that can modify the ,v-files directly, can make a lot of harm - including falsify old versions and corrupting the files. You can't do any irreversial harm (at least it shouldn't be possible) through CVS. This can be controlled through SSH (judging from your email I think you already know how). An alternative is to use a setgid cvs executable and file system permissioning. 3. We might want to grant a user to commit only to a specific branch. Would said user be able to redefine branches? If so, then such ACLs are useless from a security POV. _If_ CVS was to support access control (i.e. the way the original poster wanted to do it), there are two ways to enforce people to go through the CVS access control: 1. Disallowing cvs users to log into the server. (pserver, or the sourceforge solution - using ssh, but only allowing users to use cvs) I prefer SSH since SSH was designed with security in mind. 2. setuid'ness/setgid'ness - disallowing people to modify anything under $CVSROOT, except through the CVS tool. And how do you control who is allowed to execute the setgid cvs? Of course, in a perfect world, access control wouldn't be needed at all, because we trust each other, all right? :-) You can't really trust someone if they haven't been properly authenticated. I've tried this (on an experimental basis) and had no problems whatsoever. Probably not. Anyway, my manual does at least state that it's not constructed for it. For all I know, there might be a myriad of small security holes - haven't studied the source, so I can't tell. Of course, you wouldn't notice them until it's too late - and probably even not then. If you're that worried about security, don't use pserver. In fact, don't use CVS for security-related stuff (eg authentication or authorization). But then, how do you control who is able to execute this setgid (I wouldn't use setuid) cvs? I used file system ACLs. Of course. Set[ug]id'ness is a OS feature. Anyway it helps a lot, you might restrict the access to the $CVSROOT, so that nobody can touch it, except when using CVS. I think you misunderstood my point. How do you control who is allowed to execute this setgid cvs? One way is to use file system ACLs. Another is to control access to the directory that the cvs executable is in. I think you don't fully understand how CVS treats file system permissions. I have no problems with it. One thing is to discuss how it is, another thing is to discuss how it should be. I don't know enough of the details to understand why it makes a copy of the archive file (this may be a RCS thing). If you're able to stop this, then maybe you have a point. But then again, you still have to deal with the directory permissions. If you allow users to add or remove files, then they must have write permissions to the directories. If they have directory write permissions, then they can remove any file within that directory even if they have no permissions to the file. From another POV, I think it's no accident that SSH keeps its files in a separate directory that has extremely limited permissions. 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 access control
On Wed, Sep 26, 2001 at 10:45:50AM -0400, [EMAIL PROTECTED] wrote: When you're at it, you should also allow for different ruling on different branches, not only directories. I'm kind of against this, too, since branch-level permissions don't afford security at all since the archive file is still writable. All these ACLs will afford is a false sense of security. [no] security at all is kind of an overstatement. The security provided by a CVS-level permissions scheme would be weak, but not nonexistent. It wouldn't prevent a malicious user from committing to the wrong branch, but it would prevent people from doing so by accident/carelessness. This concurs perfectly with CVS's existing security model. For example, the up-to-date check guards against my stomping your changes by accident, but doesn't prevent me from stomping them with a bit of work (cvs up -f1.5 -j1.4 foo.c or cvs up foo.c; mv foo.bak foo.c). By definition, security is about preventing malicious users from doing harm. It's not about avoiding accidents by careless users. For example, would you consider a knotted rope tying my door shut to be any sort of security since it avoids accidental openings? For many purposes, weak protection might be good enough to protect against unwanted actions by your authorized users, in conjunction with strong security to keep out unauthorized people. Then this topic shouldn't be discussed within the frame of security. Unfortunately, ACLs are very much a security issue. Right now, I see two ways around this: 1. Create a file system that supports versioning. This file system would treat branches as it would directories. 2. Have commitinfo be able to process branch information and have the commitinfo script check for proper authorization. Since the cvs admin is the one implementing this, the cvs admin is very aware of how little security is there. 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
