Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
If I understand you correctly this is the situation: 1. There is one client workstation shared between two users 2. User1 has checked out a module from CVS to a sandbox (for example at c:\proj\mymodule) He used pserver as protocol for this operation. 3. Now User2 logs in and tries to update the sandbox and fails. The reason he fails is that the two users are two different users. The sandbox saves the information on who actually did the checkout in its administrative files. So there is an entry here in the CVS/Root files that says something like :pserver:cvsuser at cvsserver:/repository Since the pserver user is listed in the Root file you will have to log in to the cvs server if you are coming here as user2. The reason is that the login for cvsuser at cvsserver was cached in the registry when user1 did the original login prior to his checkout and now when you log on to the workstation that setting is not available to you. But if you do a cvs login and enter the password for cvsuser, then you will also cache the login in *your* registry hive and from now on you can also update the sandbox. However ------- this whole scheme is not at all optimal! You should *not* share the same sandbox between multiple developers. Instead the recommended practice is to have separate sandboxes for each user. This way the CVS server will be able to track who is doing what with the files. I would recommend that you set up your shared diskl as follows: c:\proj\user1\mymodule (Checked out by user 1) c:\proj\user2\mymodule (Checked out by user 2) And you should use cvs account names that are unique for each developer. Use sspi -------- Another way to handle this issue is *not* to use :pserver: in the first place. If you are working in Windows (as indicated here) then switch to using :sspi: instead. With sspi there is no user information stored in the CVS/Root file and so the sandbox becomes identity-free. Instead the currently logged on user will be the one that is authenticated by CVS each time you perform a cvs operation. Now the sandbox can be shared and the server will be able to save who did what to the module. /Bo -----Original Message----- From: Mac [mailto:pragcvs at yahoo.com] Sent: den 6 juni 2003 00:50 To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook Subject: [cvsnt] fail to update Hello there, The problem I am having is that when I try to login on the NT machine as myself and start WinCVS, the login to the pserver is fine. However, when try to update my working copy, it gives this msg: cvs [update aborted]: authorization failed: serve 192..... rejected access to /usr/local/cvs for user b. user b is another developer uses the same NT machine that I use. It confuse me with the other user! Your help is greatly appreciated on this matter. Thanks. --------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). _______________________________________________ cvsnt mailing list cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs