Re: Question about CVS-SSH
On Fri, Jun 10, 2005 at 02:23:03PM -0400, Huaer XC wrote: Dear CVS users: I am a newbie in this field. And I am trying to setup CVS on a Linux Mandrake server, and maintain my codes through SSH by different PCs including Win-XP and Linux system. (I followed a instruction on the following link: http://mariner.cs.ucdavis.edu/slackware/doc/applications/cvs-over-ssh.txt) Now I did the following things in my server. 1) I have setup CVSROOT in my account /home/cvs, and a repository named ABC has been imported. Since CVS is a server thing, I prefer to have the repository installed somewhere else than in my home directory. (Typically I choose /local/cvs or something like that.) [...] After I re-login to the remote workstation, and run: cve checkout ABC It return the following error info: cvs [checkout aborted]: Cannot check out files into the repository itself Is your home directory shared between your server and the workstation? The error message seems to indicate to me that you are trying to check out a copy of the repository and placing the checked out copy in the repository itself. Try placing the repository somewhere else, away from your home directory. Asbjørn ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about directory re-use (cvs status error)
Ok, This error goes away if I make the CVSROOT/EmptyDir group writeable. However, I'm curious why CVS had to resort to using the EmptyDir for this directory? The information contained in the CVS/Root and CVS/Repository files was enough to correctly identify the directory in the repository. Oh well. Because it works, my questions are purely academic now. One more observation I have on this is that there is a cvs behavioral difference between doing these two things: cvs status tools/# This was producing my EmptyDir error message cd tools/ cvs status . # This works just fine without an error (and without using EmptyDir) Todd We've got several projects that include some global tools. At this transition, I am trying to take one of the tools that we've developed in our project, push it out into the global area and check it back out into our project's working directory. I would really like to put this global tool back in the same directory so all of our Makefiles and scripts don't have to change to know about a new directory. Most things seem to work correctly, however, I'm running into an error with 'cvs status' when I do so. Please let me know if you have any thoughts on why I am seeing the error at the bottom. Thanks! Todd Everything is scripted but here are the manual steps that I have done to reproduce this problem: [[ Checkout our project ]] miller -- cvs -d :pserver:@myserver:/proj/myproj/cvsroot co -d Test proj_name This creates several directories but what I'm interested in is in the tools directory. miller -- ls -l tools/ drwxrwxr-x2 todd design 4096 Jun 9 14:15 CVS drwxrwxr-x3 todd design 4096 Jun 9 14:15 mytool miller -- ls -l tools/mytool/ drwxrwxr-x2 todd design 4096 Jun 9 14:15 CVS [[ Remove the old project-specific tool (now empty with all files in the Attic) ]] miller -- cvs release -d mytool You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `mytool': y [[ Checkout the new global tool back into the same directory ]] miller -- cvs -d :pserver:@myserver:/proj/global/cvsroot co -d mytool tools/mytool cvs checkout: Updating mytool U mytool/File1 U mytool/File2 U mytool/File3 U mytool/File4 U mytool/File5 U mytool/File6 Everything seems fine at this point, however, if I go back to the root of my working copy and do a 'cvs status tools' I get: miller -- cvs status tools cvs status: Examining tools === File: .keepdir Status: Up-to-date Working revision:1.1 Repository revision: 1.1 /proj/myproj/cvsroot/proj_name/tools/.keepdir,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) cvs status: Examining tools cvs status: failed to create lock directory for `/proj/global/cvsroot/CVSROOT/Emptydir' (/proj/global/cvsroot/CVSROOT/Emptydir/#cvs.lock): Permission denied cvs status: failed to obtain dir lock in repository `/proj/global/cvsroot/CVSROOT/Emptydir' cvs [status aborted]: read lock failed - giving up [[ I can easily change the permissions on the Emptydir directory, however I would like to know why CVS is using this directory in the first place since this has never happened before. ]] ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about WinCVS (was Info-cvs Digest, Vol 31, Issue 10)
Santosh, This is not the correct group to ask questions about WinCVS. The WinCVS message archives are accessible at http://groups.yahoo.com/messages/cvsgui. There's also a newsgroup mirror at news://news.cvsnt.org/support.cvsgui WinCVS fires off the commit command to CVSNT command line client. The commit will usually fail if there is a newer version on the server. The automatic update before commit feature (which is turned on by default in TortoiseCVS I think) would potentially mean you merged in changes without testing them first... As you may have already worked out - WinCVS uses the CVSNT command line client - if the problem is more related to that then asking on the CVSNT newsgroup should get you some answers: news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Santosh_Nandagiri Sent: Wednesday, 8 June 2005 4:02 PM To: info-cvs@gnu.org Subject: RE: Info-cvs Digest, Vol 31, Issue 10 Hello, I have a question about WinCVS. Is there any way that the user is notified every time he performs a Commit to perform an Update before doing that. Eg: It may ask the user Are you sure that you want to Commit? Did you already performed an Update? This is a requirement we are having right now, because, in some cases where there is no conflicts in the source files, there are chances of overwriting the content. Pls. respond me if any one knows the answer. Regards, Santosh. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: question about WinCVS (was Info-cvs Digest, Vol 31, Issue 10)
Greets. On 6/8/05, Arthur Barrett [EMAIL PROTECTED] wrote: Santosh, This is not the correct group to ask questions about WinCVS. The WinCVS This may be the correct group if your CVS server is running regular cvs (say on a linux box). Please provide more info: - Is your cvs server running on windows using WinCVS/cvsNT? (e.g. your CVSROOT is something like :ext:[EMAIL PROTECTED]:/var/cvs) - what is your cvs version for client and server? Regards, --Russ message archives are accessible at http://groups.yahoo.com/messages/cvsgui. There's also a newsgroup mirror at news://news.cvsnt.org/support.cvsgui WinCVS fires off the commit command to CVSNT command line client. The commit will usually fail if there is a newer version on the server. The automatic update before commit feature (which is turned on by default in TortoiseCVS I think) would potentially mean you merged in changes without testing them first... As you may have already worked out - WinCVS uses the CVSNT command line client - if the problem is more related to that then asking on the CVSNT newsgroup should get you some answers: news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Santosh_Nandagiri Sent: Wednesday, 8 June 2005 4:02 PM To: info-cvs@gnu.org Subject: RE: Info-cvs Digest, Vol 31, Issue 10 Hello, I have a question about WinCVS. Is there any way that the user is notified every time he performs a Commit to perform an Update before doing that. Eg: It may ask the user Are you sure that you want to Commit? Did you already performed an Update? This is a requirement we are having right now, because, in some cases where there is no conflicts in the source files, there are chances of overwriting the content. Pls. respond me if any one knows the answer. Regards, Santosh. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about WinCVS (was Info-cvs Digest, Vol 31, Issue 10)
See my answers: This may be the correct group if your CVS server is running regular cvs (say on a linux box). Please provide more info: - Is your cvs server running on windows using WinCVS/cvsNT? (e.g. your CVSROOT is something like :ext:[EMAIL PROTECTED]:/var/cvs) Yes. - what is your cvs version for client and server? Server 1.11, WinCVS 1.2 (client) Pls. let me know in case you have any solution or else even if you know like it is possible by introducing some kind of macro let me know. Regards, Santosh. -Original Message- From: Russ Sherk [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 10:30 PM To: Arthur Barrett Cc: Santosh_Nandagiri; info-cvs@gnu.org Subject: Re: question about WinCVS (was Info-cvs Digest, Vol 31, Issue 10) Greets. On 6/8/05, Arthur Barrett [EMAIL PROTECTED] wrote: Santosh, This is not the correct group to ask questions about WinCVS. The WinCVS This may be the correct group if your CVS server is running regular cvs (say on a linux box). Please provide more info: - Is your cvs server running on windows using WinCVS/cvsNT? (e.g. your CVSROOT is something like :ext:[EMAIL PROTECTED]:/var/cvs) - what is your cvs version for client and server? Regards, --Russ message archives are accessible at http://groups.yahoo.com/messages/cvsgui. There's also a newsgroup mirror at news://news.cvsnt.org/support.cvsgui WinCVS fires off the commit command to CVSNT command line client. The commit will usually fail if there is a newer version on the server. The automatic update before commit feature (which is turned on by default in TortoiseCVS I think) would potentially mean you merged in changes without testing them first... As you may have already worked out - WinCVS uses the CVSNT command line client - if the problem is more related to that then asking on the CVSNT newsgroup should get you some answers: news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Santosh_Nandagiri Sent: Wednesday, 8 June 2005 4:02 PM To: info-cvs@gnu.org Subject: RE: Info-cvs Digest, Vol 31, Issue 10 Hello, I have a question about WinCVS. Is there any way that the user is notified every time he performs a Commit to perform an Update before doing that. Eg: It may ask the user Are you sure that you want to Commit? Did you already performed an Update? This is a requirement we are having right now, because, in some cases where there is no conflicts in the source files, there are chances of overwriting the content. Pls. respond me if any one knows the answer. Regards, Santosh. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question on branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please do not use HTML e-mail. Zeus Crisp [EMAIL PROTECTED] writes: Hello all, Hoping someone can help as I am a new users to CVS. I would like to know if there is a way to lock a specific branch to block commits within a CVS environment. We have an environment where we have several branches all created off main. I would like to have the ability to manage the branches indivdually where I can allow only certian users to commit changes to which ever branch. Currently I can apply a lock to the entire CVS repository but there are times when I don't want commits to occur in branch-A but there is no reason to block the commits to branch-B. I would also like to be able to dictate who can perform the commits. Read https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.html?rev=HEAD Fetch, configure and deploy: https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in?rev=HEAD You may find searching lists.gnu.org useful. Here is an interesting thread: http://lists.gnu.org/archive/html/cvs-utils/2004-02/msg00047.html Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFChviX3x41pRYZE/gRAh1wAKDhDP0IRyXystGoK527J19hIxN0aQCfT3Qa 0elk+gSxwG4L4Bci9q1CKFI= =T5Ht -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about binary distribution
From: Arthur Barrett hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i cant find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? You may also need cygwin and other tools to run this version of CVS on Windows Server 2003. The Windows CVS client binary distributed by the CVS Project is compiled using Microsoft Visual Studio 6.0 and does NOT require Cygwin or any other software. The compiled EXE is statically linked, requires no DLL libraries and runs alone as is. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about binary distribution
Conrad, hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can´t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? You may also need cygwin and other tools to run this version of CVS on Windows Server 2003. The Windows CVS client binary distributed by the CVS Project is compiled using Microsoft Visual Studio 6.0 and does NOT require Cygwin or any other software. The compiled EXE is statically linked, requires no DLL libraries and runs alone as is. Yes you are right - my mistake. I was thinking of the SSH support. Am I right in assuming that cvshome cvs requires cygwin for ssh support on windows? I also think I saw a post recently somewhere saying that cygwin ssh is not windows 2003 compatible... Regards, Arthur ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about binary distribution
Sorry if this has been answered already... If you want to run it on Windows you'll need to go to http://www.cvsnt.org and download the Windows binaries for CVSNT. Thanks, Don Zielke American Electric Power Direct (614) 583-6337 Audinet 8-220-6337 Email dzielke (at) aep.com --- KForce Professional Staffing 501 W. Schrock Road Suite 207 Westerville, OH 43081 Conrad T. Pino [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/03/2005 02:14 AM To:HSP [EMAIL PROTECTED], info-cvs@gnu.org cc: Subject:RE: Question about binary distribution The ZIP file you downloaded contains a CVS client suitable for running against the Win32 API (Windows 9x, Me, NT, 2000, XP, 2003). The CVS Project does NOT support server mode on any Windows version. Other projects do implement CVS compatible servers on Windows but since I don't know any of them well I'm reluctant to make a recommendation and leave that to others. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of HSP Sent: Monday, May 02, 2005 13:09 To: info-cvs@gnu.org Subject: Question about binary distribution hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can´t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? thanks in advance!! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about binary distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Barrett [EMAIL PROTECTED] writes: hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can=B4t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? You may also need cygwin and other tools to run this version of CVS on Windows Server 2003. The Windows CVS client binary distributed by the CVS Project is compiled using Microsoft Visual Studio 6.0 and does NOT require Cygwin or any other software. The compiled EXE is statically linked, requires no DLL libraries and runs alone as is. Yes you are right - my mistake. I was thinking of the SSH support. Am I right in assuming that cvshome cvs requires cygwin for ssh support on windows? You should be able to use Putty by setting up your CVS_RSH environment variable without needing cygwin. Of course, you would need to download Putty and maybe Pagent as well, but neither of them require cygwin. I also think I saw a post recently somewhere saying that cygwin ssh is not windows 2003 compatible... That is something to address with the cygwin and/or OpenSSH folks as it is outside the scope of CVS dependencies. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCeTyt3x41pRYZE/gRAmqzAJ9Pmh1nY1u3hRQ7sVkQERT+zZNvfwCeJtPB CoMpi1tQXL3DCIzvk587W7w= =DZ1B -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about binary distribution
(gnu.cvs.help trimmed from recipient list; I can't access it) HSP wrote: hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can´t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? thanks in advance!! If you're using Windows as your server, then you probably would be better off using CVSNT on your server: www.cvsnt.org Clients can use either CVSNT or cvshome's CVS. -- Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about binary distribution
hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i cant find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? You may also need cygwin and other tools to run this version of CVS on Windows Server 2003. Alternatively the free/GPL CVSNT server and client is a more common solution for Windows Server 2000 and 2003 installations: http://www.cvsnt.org/ Please direct questions about CVSNT to the CVSNT newsgroup: news://news.cvsnt.org/support.cvsnt or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Regards, Arthur Barrett ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about binary distribution
The ZIP file you downloaded contains a CVS client suitable for running against the Win32 API (Windows 9x, Me, NT, 2000, XP, 2003). The CVS Project does NOT support server mode on any Windows version. Other projects do implement CVS compatible servers on Windows but since I don't know any of them well I'm reluctant to make a recommendation and leave that to others. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of HSP Sent: Monday, May 02, 2005 13:09 To: info-cvs@gnu.org Subject: Question about binary distribution hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can´t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? thanks in advance!! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question About CVS
Jacky Cheang writes: Does it update to the server via HTTP or FTP connections? No. Remote access is via a remote command facility like rsh or ssh, or a proprietary protocol (pserver). Of those, only ssh is recommended for use across the public internet. I believe the current feature release of CVS has some provisions for using an HTTP proxy server to traverse firewalls, but I don't know the details. -Larry Jones It must be sad being a species with so little imagination. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question re: deleted tags
Larry Jones wrote: Derek Price writes: Well, fixing it this way would put us back in the position where checkouts and updates could sometimes report that tags don't exist when they do. I think this is worse than not checking out any data when the tag doesn't exist in the project or sub-project being checked out (which can happen anyhow when the tag is correctly in val-tags). I just fixed this on feature by having the tag command itself update the cache. I think you've forgotten how val-tags works. If a tag appears in the val-tags file, it is assumed to be valid and no error is issued, even though the tag may not appear in any of the files being processed. If the tag does not appear in the val-tags file, then CVS examines all of the files to be processed. If the tag occurs in any of them, then it is valid and is added to the val-tags file; if not, then -- and only then -- do you get the tag does not exist error. I think that may have been the intention, but I don't think that's the way it really works. First, take a look at the dirs2-10 rmadd-17 tests on stable (they've been eliminated on feature). They show that commit commands and sometimes update commands will sometimes both issue no such tag errors when they shouldn't. Hence the warning in the manual about trying some combination of commands until val-tags gets updated when encountering this message. So, obviously, some commands were not recursing when they didn't find the tag in val-tags. It's possible I took the wrong approach to fixing this bug. Not that what I did was bad, but perhaps I should have figured out why some commands were failing to search for the tag and fixed those? Derek ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
I understand WHY now. Since val-tags is just a cache, where is the real tags repository. Again in my last post, I said I did NOT see the deleted tag in val-tags anymore, and don't see a tag that should still be there. -chris -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 5:56 PM To: Derek Price Cc: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: Re: Question re: deleted tags Derek Price writes: Since tag deletion is considered a relatively rare operation (as well it should be), no one has ever bother to write the code for the expensive, complete tag search that would be necessary to determine if the tag is really completely gone and should really be deleted from val-tags. It's not necessary -- since val-tags is just a cache, it would be safe to just delete it regardless. Of course, the first thing that needs to be done is to add some kind of locking for the val-tags file since there isn't any right now and the more we update it the better the chance of it getting corrupted by simultaneous updates. -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
I believe that the real tags repository, as you call it, is knowledge scattered in each ,v file in the repository. Each file lists the tags with which it is tagged. That's why when you specify a tag that is not in the val-tags file it can take a long time to process the command; CVS has to look at every ,v file in the module(s) referenced in the command to see if the tag exists. -- Rick Genter Principal Engineer Silverlink Communications mailto:[EMAIL PROTECTED] (781) 272-3080 x242 This e-mail, including attachments, may include confidential and/or proprietary information, and may only be used by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, January 20, 2005 11:04 AM To: info-cvs@gnu.org Subject: RE: Question re: deleted tags I understand WHY now. Since val-tags is just a cache, where is the real tags repository. Again in my last post, I said I did NOT see the deleted tag in val-tags anymore, and don't see a tag that should still be there. -chris -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 5:56 PM To: Derek Price Cc: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: Re: Question re: deleted tags Derek Price writes: Since tag deletion is considered a relatively rare operation (as well it should be), no one has ever bother to write the code for the expensive, complete tag search that would be necessary to determine if the tag is really completely gone and should really be deleted from val-tags. It's not necessary -- since val-tags is just a cache, it would be safe to just delete it regardless. Of course, the first thing that needs to be done is to add some kind of locking for the val-tags file since there isn't any right now and the more we update it the better the chance of it getting corrupted by simultaneous updates. -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
Yep, I should've know that because I've seen the real tags in the ,v files. Thanks!!! -chris -Original Message- From: Rick Genter [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 11:37 AM To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: RE: Question re: deleted tags I believe that the real tags repository, as you call it, is knowledge scattered in each ,v file in the repository. Each file lists the tags with which it is tagged. That's why when you specify a tag that is not in the val-tags file it can take a long time to process the command; CVS has to look at every ,v file in the module(s) referenced in the command to see if the tag exists. -- Rick Genter Principal Engineer Silverlink Communications mailto:[EMAIL PROTECTED] (781) 272-3080 x242 This e-mail, including attachments, may include confidential and/or proprietary information, and may only be used by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, January 20, 2005 11:04 AM To: info-cvs@gnu.org Subject: RE: Question re: deleted tags I understand WHY now. Since val-tags is just a cache, where is the real tags repository. Again in my last post, I said I did NOT see the deleted tag in val-tags anymore, and don't see a tag that should still be there. -chris -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 5:56 PM To: Derek Price Cc: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: Re: Question re: deleted tags Derek Price writes: Since tag deletion is considered a relatively rare operation (as well it should be), no one has ever bother to write the code for the expensive, complete tag search that would be necessary to determine if the tag is really completely gone and should really be deleted from val-tags. It's not necessary -- since val-tags is just a cache, it would be safe to just delete it regardless. Of course, the first thing that needs to be done is to add some kind of locking for the val-tags file since there isn't any right now and the more we update it the better the chance of it getting corrupted by simultaneous updates. -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question re: deleted tags
[EMAIL PROTECTED] writes: I understand WHY now. Since val-tags is just a cache, where is the real tags repository. The individual RCS files in the repository. -Larry Jones I thought my life would seem more interesting with a musical score and a laugh track. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
-Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2005 4:25 PM To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: RE: Question re: deleted tags Christopher Fouts wrote: What am I missing? CVSROOT/val-tags Tags never get removed from val-tags. The no such tag message will appear only if the tag does not appear in val-tags. If the tag appears in val-tags, then CVS has to search each file in each directory to determine which files may or may not have the tag. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) Tags never get removed from val-tags. Why? If I delete a tag, I I want to, well, delete it! -chris ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Fouts Christopher (IFNA MP DC) Sent: Wednesday, January 19, 2005 8:46 AM To: info-cvs@gnu.org Subject: RE: Question re: deleted tags -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2005 4:25 PM To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: RE: Question re: deleted tags Christopher Fouts wrote: What am I missing? CVSROOT/val-tags Tags never get removed from val-tags. The no such tag message will appear only if the tag does not appear in val-tags. If the tag appears in val-tags, then CVS has to search each file in each directory to determine which files may or may not have the tag. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) Tags never get removed from val-tags. Why? If I delete a tag, I I want to, well, delete it! -chris ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs Ok, I'm even more confused now. I looked at my CVSROOT/val-tags file and it does NOT have the deleted tag. Even more confusing, it does NOT have some valid tags that I use? So again, what am I missing? -chris ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question re: deleted tags
Derek Price writes: Since tag deletion is considered a relatively rare operation (as well it should be), no one has ever bother to write the code for the expensive, complete tag search that would be necessary to determine if the tag is really completely gone and should really be deleted from val-tags. It's not necessary -- since val-tags is just a cache, it would be safe to just delete it regardless. Of course, the first thing that needs to be done is to add some kind of locking for the val-tags file since there isn't any right now and the more we update it the better the chance of it getting corrupted by simultaneous updates. -Larry Jones I'm so disappointed. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question re: deleted tags
Larry Jones wrote: Derek Price writes: Since tag deletion is considered a relatively rare operation (as well it should be), no one has ever bother to write the code for the expensive, complete tag search that would be necessary to determine if the tag is really completely gone and should really be deleted from val-tags. It's not necessary -- since val-tags is just a cache, it would be safe to just delete it regardless. Of course, the first thing that needs to be done is to add some kind of locking for the val-tags file since there isn't any right now and the more we update it the better the chance of it getting corrupted by simultaneous updates. Well, fixing it this way would put us back in the position where checkouts and updates could sometimes report that tags don't exist when they do. I think this is worse than not checking out any data when the tag doesn't exist in the project or sub-project being checked out (which can happen anyhow when the tag is correctly in val-tags). I just fixed this on feature by having the tag command itself update the cache. Regards, Derek ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question re: deleted tags
Derek Price writes: Well, fixing it this way would put us back in the position where checkouts and updates could sometimes report that tags don't exist when they do. I think this is worse than not checking out any data when the tag doesn't exist in the project or sub-project being checked out (which can happen anyhow when the tag is correctly in val-tags). I just fixed this on feature by having the tag command itself update the cache. I think you've forgotten how val-tags works. If a tag appears in the val-tags file, it is assumed to be valid and no error is issued, even though the tag may not appear in any of the files being processed. If the tag does not appear in the val-tags file, then CVS examines all of the files to be processed. If the tag occurs in any of them, then it is valid and is added to the val-tags file; if not, then -- and only then -- do you get the tag does not exist error. -Larry Jones Mom would be a lot more fun if she was a little more gullible. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question re: deleted tags
Christopher Fouts wrote: What am I missing? CVSROOT/val-tags Tags never get removed from val-tags. The no such tag message will appear only if the tag does not appear in val-tags. If the tag appears in val-tags, then CVS has to search each file in each directory to determine which files may or may not have the tag. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question on modules file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yamuna Ramasubramaniyan [EMAIL PROTECTED] writes: I have a problem using a directory name with a space in it in the modules file. Can the modules file not support spaces in the directory name? Correct. Spaces in file and directory names are not well supported in CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBmb+43x41pRYZE/gRArg3AJ99U5WICpjICQWygPaynnH+7EiZgwCg0bqx MdUpe9W33X8wGvuvIUTclHk= =htE2 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question regarding cvs admin
Godavarthi, Manasa writes: I had to change a branch name and by accident I went into the repository(CVS ROOT) itself and executed the following command : cvs admin -nNew_Branch_Name:Old_Branch_Name And it gave me message saying Administering each module_name I am not sure if I erased some repositories or changed something. Please somebody tell me that nothing would have happened. It's hard to say. If you really did what you said, you should have gotten: cvs [admin aborted]: there is no version here; run 'cvs checkout' first So, either you're running a very old version of CVS, you didn't do what you said you did, or your repository is (or appears to be) checked out from another repository. -Larry Jones OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about rtag command.
Title: question about rtag command. That works for the trunk, but I was looking at being able to tag the status of a branch at a specified date/time. Harold -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Stuart StevensSent: Tuesday, November 09, 2004 5:08 PMTo: Lynch, Harold; [EMAIL PROTECTED]Subject: RE: question about rtag command. Normally you would use Cvs q rtag -D datestring new tag module to tag Stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, HaroldSent: Tuesday, November 09, 2004 12:09 PMTo: [EMAIL PROTECTED]Subject: question about rtag command. Is it possible (with cvs 1.11.x) to tag a branch by date? I've tried a couple of permutaions of cvs -q rtag -r branchtag -D datestring modulename But I'm not sure if it is doing what I think it's doing. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: question about rtag command.
Title: question about rtag command. Normally you would use Cvs q rtag -D datestring new tag module to tag Stuart From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, Harold Sent: Tuesday, November 09, 2004 12:09 PM To: [EMAIL PROTECTED] Subject: question about rtag command. Is it possible (with cvs 1.11.x) to tag a branch by date? I've tried a couple of permutaions of cvs -q rtag -r branchtag -D datestring modulename But I'm not sure if it is doing what I think it's doing. Harold Lynch ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question
Gleidson S? Barreto [EMAIL PROTECTED] wrote: 1-To take place the transfer of the files stored in the repository q they were modified for your work area, through a sicroniza??o operation. Like this, would to be in fact that sicroniza??o operation? I'm not sure what you mean, but... Synchronization in both direction has to be requested explicitly, by running a command. cvs update to receive changes made by others, and cvs commit to send changes made by you. 2-CVS counts with a mechanism capable to control the simultaneous accesses and the parallel modifications, guaranteeing like this the integrity of the modifications and atomicity of the operations. Would be in fact that atomicity of operations? If I remember correctly, commits are atomic within any one directory but are not atomic across entire hierarchies. Commits are certainly atomic on a file by file basis, so you do not get corrupted files. The lack of atomicity occurs when a developers performs an update (receive) while another developer performs a commit (send). The receiving developer may get an inconsistent snapshot with some files just before their commit and some other files just after the commit. The workaround is to repeat the update. It would be a little difficult to notice in practice, because when working on an active project one has to update many times every day. Also, the trunk tends to be somewhat unstable since it is being actively modified. 3-CVS possesses mechanism capable to identify and to solve conflicts. However those identified conflicts are merely textual, not existing any analysis of the logical consistence. Here I didn't understand the expression textual conflicts very well. A textual conflict occurs when two people modified lines at overlapping locations in a file, or at nearly overlapping locations (~3 lines apart or so). These conflicts have to be resolved manually. Modifications in distant parts of the file are accepted uncritically. You are correct that this could introduce logical errors in the merged file; the amazing thing is that it almost never does, because of the way people write software. In any case, cvs always gives you backup copies of the two conflicting versions of the file. -- pa at panix dot com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question about chacl
Jeffrey, CVSNT has it's own mailing list: news://news.cvsnt.org/support.cvsnt Or http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt I suggest you ask there (and perhaps consider upgrading to the latest release): http://www.cvsnt.com Regards, Arthur Barrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JeffreyC Sent: Tuesday, 14 September 2004 10:40 AM To: [EMAIL PROTECTED] Subject: Question about chacl I'm trying to set permissions for a projectd using chacl and am unable because the initial cvs checkout is apparently not work. We have a large repository with many projects in place, and I've been using cvs checkout for months now, usually for deployments and tagging; but for some reason in this instance it is not working. Here's what I'm doing: cvs checkout -r HEAD ProjectName (This works fine) cvs chacl -R chacl cvsadmin:r ProjectName (This results in the following message:) cvs chacl: in directory .: cvs [chacl aborted]: there is no version here; do 'cvs checkout' first I can't even perform a simple listing of permissions using lacl on that project -- that command returns the same message. Any suggestions would be much appreciated. Some details: OS: Windows Server 2003 CVS: CVSNT 2.0.38 ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
K. Posern [EMAIL PROTECTED] writes: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? CVS doesn't have support for that. You'd have arrange to update any separate checked-out versions on the server yourself using a script. Take a look at the hooks like 'commitinfo' and loginfo' for ways to do that. -- Brian Gough Network Theory Ltd, Publishing the CVS Reference Manual --- http://www.network-theory.co.uk/cvs/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
Hi. I am a CVS newbie and I would like to do/have the following: On the clients I work with: CVSROOT=:ext:[EMAIL PROTECTED]:/var/lib/cvs; LOCAL=/SOMEWHERE/sv; CVS update is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT update -dP; CVS commit is done by: cd /SOMEWHERE/sv; cvs -d $CVSROOT commit; cvs -d $CVSROOT makes little sense... cvs uses $CVSROOT by default I describe all this because I dunno if you might need this information to answer me the following question: I thought that the CVS-Tree LOCAL and on the SERVER are IDENTICAL (after I did an update). But on the server the files end with ,v and have all the comments and version stuff inside. I now know that these files are the rcs files (the backbone of the cvs?). more or less. Never touch the files in $CVSROOT But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? See keeping a checked-out copy https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 Arno ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
Hello, * On Thu, Aug 26, 2004 at 12:20:14PM +0200 K. Posern wrote: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). Have a look at C.3.5.2 of your manual: https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC175 HTH, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about RCS files
K. Posern wrote: But I need an exact copy of the version a CLIENT has in its /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff). How can I achieve this? Do I have to to do an cvs-checkout on the server and cvs-update everytime a client did commit something? Or can I say to the server somehow to keep automatically the rcs stuff seperate in one dir and an client-like-copy of the cvs-repository in another dir? You have to do a cvs-checkout into a separate directory on the server, and then perform a cvs-update every time a client does a commit. In UN*X you can do the checkout on a cron job periodically. In Windows I think you can use cygwin to set up a cron job as well. You could also abuse the loginfo script so that after every commit the server runs a cvs update in you checked-out directory. See https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167 Cheers, Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold wrote: I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? I had a problem like this that ultimately turned out to be a network card misbehaving, particularly with ssh. Andrew Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold wrote: I'm trying to look into a problem with the amount of time it takes us to do a checkout of a large (800 meg) module. On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. When I look at top on the cvs server, the process associated with the pulls to that machine get very little cpu. Is there any kind of scheduling going on inside the cvs server process (aside from blocking for io)? Harold Lynch Have you looked at top on the slow machine? You did not indicate if it has a bitty processor, compared to others, or if it has a lot of work happening on it all the time, or even if it has an old slow hard drive that the 800 meg is getting written to. Oh you are using :ext: or :pserver: access method right? Have you made sure the network connection to the slow machine is as fast as the others and in good repair? (Assuming Unix) check the output of ifconfig if the following are not 0 you might have a bad cable/hub/card errors:0 dropped:0 overruns:0 carrier:0 (not necessarily a good indicator, mine has a few here) check with ping `ping -c100 -s1492 slowmachine` if there is any loss in a LAN, something is going on you need to look into. `time ping -f -c1000 -s1492 slowmachine` for a slow processor machine on a 10Mb/s LAN the loss here should still be sub 20%. and running `time ping -f -c1000 -s1492` against a fast machine too might give you some insight. also the following might you measure the path. http://freshmeat.net/projects/netio/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about process scheduleing
Lynch, Harold writes: On most of the machine in the shop it takes between 10 and 15 minutes, on one machine it can take an hour. Look for network problems with that machine -- that sounds like dropped packets and retransmissions. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Question regarding branch merges
cvs update -dP ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question regarding branch merges
I've asked this before. This is design intent - you WILL have to create the new dirs/files on the trunk onto your branch MANUALLY! -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Lancisi Sent: Friday, May 14, 2004 2:02 PM To: [EMAIL PROTECTED] Subject: Question regarding branch merges I've got a branch that I've been keeping in line with the HEAD of the trunk by merging via : cvs update -d -j foottag -j HEAD in my branch sandbox, and then committing the results and moving the foottag on the trunk to the HEAD . This works great.. However - there is one issue I'm seeing.. New directories on the trunk (and any new files in them) do not get merged into my sandbox. New files in existing directories do, but new directories containing new files do not. Does anyone have any idea if this is a design limitation or a bug in cvs? Or am I just doing something wrong? Thanks in advance! Mark Lancisi ___ 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: Question about upgrading.
Lynch, Harold writes: After looking though the ChangeLogs etc, I was wondering if there is a list of behavior changes from version to version. I think you'll find NEWS to be of more value than the ChangeLogs. -Larry Jones It's a Doofus Ignoramus! Our hero slowly reaches for his stun blaster! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on repository file permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fouts Christopher (6452) [EMAIL PROTECTED] writes: I have a sample project with r-s permissions for g and o. I have dir1/file1 directory/file in the project, which user cvsadmin in the cvs group, created. so now file1 has r--r--r-- permissions. I have a separate lock direcotry, called /cvsroot/lockDir with rwxrwsrwx permissions. Now user1 in group user checks out sample and modifies file1. When user1 checks in file1, it gets Could not open file /cvsroot/sample/dir1/file1, permission denied. I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea behind the LockDir was for me (cvs admin) NOT to have to do this? The idea behind LockDir is to allow folks to do read-only checkouts of files that they may not normally be allowed to commit as well as to allow for performance improvements of a very fast in-memory filesystem for the LockDir. There are multiple reasons that a LockDir might be desirable including that this may be a read-only mirror of the main cvs repository that is being updated via CVSup or some other similar mechanism or that the filesystem is very slow for writes and an in-memory filesystem is available to deal with cvs locks. If you want a given user to be able to commit, you still need for the directories to have appropriate permissions as the new ,foo, file must still be created within the repository and then renamed as foo,v for each commit or tag operation. Reread http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAdYEL3x41pRYZE/gRAjBHAKDDgn/+/8/cUgaZv9dH5wft18MceQCdEeRP JXvVXAgA0R8tpRp8GXEBcjM= =D4SI -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on repository file permissions
Fouts Christopher (6452) wrote: I have a sample project with r-s permissions for g and o. I have dir1/file1 directory/file in the project, which user cvsadmin in the cvs group, created. so now file1 has r--r--r-- permissions. I have a separate lock direcotry, called /cvsroot/lockDir with rwxrwsrwx permissions. Now user1 in group user checks out sample and modifies file1. When user1 checks in file1, it gets Could not open file /cvsroot/sample/dir1/file1, permission denied. I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea behind the LockDir was for me (cvs admin) NOT to have to do this? - Chris T Fouts checkin requires the user to write to the repository, for this user1 needs write privileges to the REPOSITORY. i.e. ls -ld /cvsroot/sample/dir1/ #should yield something like: drwxrwsr-x # cmuser projgrp512 Jan 26 10:51 /cvsroot/sample/dir1/ #and ypcat group /tmp/look; cat /etc/group /tmp/look| grep user1 #should yield something like projgrp::530:user1,me,restofgroup LockDir lets you allow more people to read than to write, i.e. you can set it up so marketing and the PHB can read the repository but never commit. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question on repository file permissions
Thanks to all!
-chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 12:43 PM
To: Fouts Christopher (6452)
Cc: [EMAIL PROTECTED]
Subject: Re: Question on repository file permissions
References:
[EMAIL PROTECTED]
From: Mark D. Baushke [EMAIL PROTECTED]
X-Mailer: MH-E 7.4.3+cvs; nmh 1.0.4; GNU Emacs 21.1.1
X-Face:
#8D_6URD2G%vC.hzUdI#Y9szHj$'mGtUqd=rXy^L$-=G_-LmZ^5!Fszk:yXZp$k\nTF?
8Up0!v/%1Q[(d?ES0mQW8dRCXi18gK)luJu)loHk,}4{Vi`yX?p?crF5o:LL{6#eiO:(E:YMxLXU
LB
k|'a*EjN.BL+[J!PhJ*aX0n:5/
Mail-Followup-To: info-cvs [EMAIL PROTECTED],[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Apr 2004 09:42:51 -0700
Message-ID: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
=2DBEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fouts Christopher (6452) [EMAIL PROTECTED] writes:
I have a sample project with r-s permissions for g and o.
I have dir1/file1 directory/file in the project, which user cvsadmin
in the cvs group, created. so now file1 has
r--r--r-- permissions.=20
=20
I have a separate lock direcotry, called /cvsroot/lockDir with
rwxrwsrwx permissions. =20
Now user1 in group user checks out sample and modifies
file1. When user1 checks in file1, it gets
Could not open file /cvsroot/sample/dir1/file1, permission denied.
=20
I fixed it by chmod -R o+w /cvsroot/sample. I thought the idea
behind the LockDir was for me (cvs admin) NOT to have to do this?
The idea behind LockDir is to allow folks to do read-only checkouts of files
that they may not normally be allowed to commit as well as to allow for
performance improvements of a very fast in-memory filesystem for the
LockDir.
There are multiple reasons that a LockDir might be desirable including that
this may be a read-only mirror of the main cvs repository that is being
updated via CVSup or some other similar mechanism or that the filesystem is
very slow for writes and an in-memory filesystem is available to deal with
cvs locks.
If you want a given user to be able to commit, you still need for the
directories to have appropriate permissions as the new ,foo, file must still
be created within the repository and then renamed as foo,v for each commit
or tag operation.
Reread http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_18.html
-- Mark
=2DBEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFAdYEL3x41pRYZE/gRAjBHAKDDgn/+/8/cUgaZv9dH5wft18MceQCdEeRP
JXvVXAgA0R8tpRp8GXEBcjM=3D
=3DD4SI
=2DEND PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on repository file permissions - part 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fouts Christopher (6452) [EMAIL PROTECTED] writes: I have a sample project in /cvsroot I have a cvsadmin user in group cvs to manage the sample project. cvsadmin is also in group users. cvsadmin initially created /cvsroot/sample/dir1/file1, and changed group ownership to users. I have a user1 in group users who wants to read from and commit to the repository. How do I set up my rwx permissions so ALL members of group users can checkout/checkin from/to the repository, but ONLY cvsadmin can directly access the repository, that is, through a regular unix session and not via cvs. If I do chmod g+rwxs sample, anyone in group users can directly access the repository (i.e., delete files). If I do a g-w, users can only checkout, but not checkin. -chris There is a thread on this from February 2004 http://mail.gnu.org/archive/html/info-cvs/2004-02/msg00359.html http://mail.gnu.org/archive/html/info-cvs/2004-02/msg00360.html http://mail.gnu.org/archive/html/info-cvs/2004-03/msg0.html Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAdaom3x41pRYZE/gRAiTLAJ9zrWWen+fncYeEcdf++ewm1BOBrwCgsg3d 5Uoj9RXfOBO8wZFLfALZBXs= =OSA+ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question: Windows Build - feature branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This discussion is more appropriate for bug-cvs. I've cc'd it but left info-cvs in this round so that interested parties can follow the thread to the new list. Please remove info-cvs from the CC list in replies. Conrad T. Pino wrote: = I'm surprised by, As long as no one else takes responsibility for the Windows build files... and concerned that responsibility for the Windows build devolved to you since time spent on build mechanics is time lost from usable enhancements. Keep me in mind if there's something you can delegate keeping in mind I've a lot left to learn. Thanks for the cote of ocnfidence. As for delegation, it sounds like you're off to a good start. I assume the Windows CVS binary supplied at cvshome.org is widely used as the preferred binary command line version and perhaps underneath WinCVS also but I'd like to hear your perspective first before acting. WinCVS has started defaulting to using CVSNT, though I think it is still possible to plug in our CVS. I'd really like to see CVSNT merge with CVS again since both projects have lots of good work being done on them. If you run out of Windows tasks, porting CVSNT features back to CVS one at a time until the code bases match would be useful work. = We're in a mixed Visual C++ (VC) 5.0 6.0 mode because supporting 5.0 is still the project goal but the current contributors have limited access to VC versions. I'm aware of only you, Dennis Jones and I are actively dabbling with the Windows build. Can you say who the other active stake holders in the Windows build process are? Is dropping support for VC 5.0 in favor of VC 6.0 an option? I think Dennis objected to that. As long as someone else is regenerating the build files when necessary, I don't mind checking them in. Is adding a complete set distinctly named VC 6.0 build files and keeping VC 5.0 files in a semi-maintained state an option? = Relying on a commercial compiler that isn't compatible with the *nix build process strikes me at odds with most open source practice. I'm concerned that maintaining distinct builds is seems problematic in a resource constrained project. What is the current level of support for building CVS with gcc on Windows? It can be done with Cygwin, but the executable built is only useful from the Cygwin Bash shell, as far as I can tell. I think I jumped through some hoops once to enable the Cygwin binary to find the Cygwin DLL, but we still couldn't ship the binary since users would need to install Cygwin to use CVS. I haven't tried the DJGPP version of GCC yet. It is possible that it doesn't suffer from the same limitations as Cygwin. If you have time to research that and would like to report back, I would like to hear. Is dropping VC support in favor of gcc on Windows an option? Not unless we can build a binary that works without the build envirionment installed, I think. It might be interesting to look into what CVSNT is doing in this area too since they have a more Windows-centric focus. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAcYxDLD1OTBfyMaQRAu9TAJ9UvmrD7a+Ikrr5ggFZihuXDUg7PACg1odd omnb3HCJx46GKpCqRkM01lM= =7cMl -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question: Windows Build - feature branch
Hi Derek, From: Derek Robert Price [mailto:[EMAIL PROTECTED] May I assume this choice is deliberate and won't change soon? Well, yes and no. The decision to stick with 5.0 hasn't really changed, but for practical reasons, when it becomes necessary to update the build files, I use 6.0 (I only have MSVC++ 6.0). As long as no one else takes responsibility for the Windows build files, this is probably the way it will stay. When I recently updated the build files, Dennis Jones re-regenerated the *.mak files with 5.0. If he keeps this up, then I have no problem checking the 5.0 files in. = I'm surprised by, As long as no one else takes responsibility for the Windows build files... and concerned that responsibility for the Windows build devolved to you since time spent on build mechanics is time lost from usable enhancements. Keep me in mind if there's something you can delegate keeping in mind I've a lot left to learn. I assume the Windows CVS binary supplied at cvshome.org is widely used as the preferred binary command line version and perhaps underneath WinCVS also but I'd like to hear your perspective first before acting. = We're in a mixed Visual C++ (VC) 5.0 6.0 mode because supporting 5.0 is still the project goal but the current contributors have limited access to VC versions. I'm aware of only you, Dennis Jones and I are actively dabbling with the Windows build. Can you say who the other active stake holders in the Windows build process are? Is dropping support for VC 5.0 in favor of VC 6.0 an option? Is adding a complete set distinctly named VC 6.0 build files and keeping VC 5.0 files in a semi-maintained state an option? = Relying on a commercial compiler that isn't compatible with the *nix build process strikes me at odds with most open source practice. I'm concerned that maintaining distinct builds is seems problematic in a resource constrained project. What is the current level of support for building CVS with gcc on Windows? Is dropping VC support in favor of gcc on Windows an option? = Derek Conrad ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question: Windows Build - feature branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: After checking Windows build files in archive I've noted the project is using different versions of Visual C++ in that: 1. Visual C++ 6.0 to maintain *.dsw, *.dsp files. 2. Visual C++ 5.0 to maintain *.mak files. May I assume this choice is deliberate and won't change soon? Well, yes and no. The decision to stick with 5.0 hasn't really changed, but for practical reasons, when it becomes necessary to update the build files, I use 6.0 (I only have MSVC++ 6.0). As long as no one else takes responsibility for the Windows build files, this is probably the way it will stay. When I recently updated the build files, Dennis Jones re-regenerated the *.mak files with 5.0. If he keeps this up, then I have no problem checking the 5.0 files in. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQFAbyvALD1OTBfyMaQRAlGaAJ41SgYk0CkbT89vihLLmfNJbbBfiQCfR2wQ PzB0ol2xVZ1kFPTje/qOazY= =AIwX -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about links
--- Forwarded mail from [EMAIL PROTECTED] Lynch, Harold [EMAIL PROTECTED] writes: This may be a wierd one.=20 =20 If there are two different repositories on one machine, would it be a bad thing to link part of one repository to the other. =20 I.E. =20 if there is a module in repository A call whatever, and the dir is linked to repository B will the cvs server (we are using pserver method), handle it correctly? I will assume that by 'linked' you mean that one of the repositories has a symbolic link to the directory in the other repository... You will NOT be able to use LockDir with either of the repositories involved. You will also need to take care that the commit criteria of your CVSROOT *info scripts are consistent across both repositories... You will also want to have a consistent understanding of how your users map across both repositories. In fact, you will probably end up with a great deal of CVSROOT being duplicated between the two to get this to work. So, you need to ask yourself why you even bother to have two separate repositories on the machine... That said, I have not tried the setup you suggest. It might work, but it is probably not the best idea I have seen mentioned. I have used such a method successfully in the past, but I would not recommend it. It's much better to write the overlap into your modules definitions, though that method also has its limitations. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question
fred wrote: already have setup a cvs depository on solaris 2.8 system running on unix port 2409. how can i create additional repositories on the same box?. what is the best way to hanlde this?. What is the issue ? * create a new directory (repository) * cvs -d directory init * add a --allow-root=directory to the pserver It's all in the docs. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 fred [EMAIL PROTECTED] writes: already have setup a cvs depository on solaris 2.8 system running on unix port 2409. how can i create additional repositories on the same box?. what is the best way to hanlde this?. There are a few ways. One is to just add multiple --allow-root=/path/to/another/repository arguments. Another would be to run the additional repositories on another port. Depending on system command-line limits in your inetd.conf file, you may need to wrap all of the arguments for your cvs pserver command into a script and have the script run by your inetd process. For example, read the URL: http://mail.gnu.org/archive/html/info-cvs/2002-12/msg00336.html Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/msyG3x41pRYZE/gRAjzeAKDCzZm6mQvhyeKaOvJo+FkbIQ3eiQCffGss HDPVCh2WbFU0G4eIA9Z9OQI= =yUQO -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about $log$ and merging
On Thu, 19 Sep 2002, David Rosenstrauch wrote: We're running into this exact problem. We just merged from a branch back onto the trunk this morning, but got a ton of merge conflicts - all of them having to do with the $Log$ keyword. None of the -k substitution options are fixing the problem (-ko, -kk) - and they're even causing more problems, since they whack the -kb status that binary files have. Anyone know of any workarounds to this situation? The workaround is to delete $Log$ from all your files, along with all the crap it has ever generated. Then commit. Treat any conflict within a $Log$-generated text area as irrelevant; just blow away the whole section including the conflict. The $Log$ keyword is next to useless, because all it does is reproduce information that is already available in the repository. Unless the commit messages are conscientiously written, they are unlikely to be of value to anyone, and even if they are so written, they won't be of use to anyone who has no access to the repository, because they describe changes recorded in inaccessible past versions. You need access to the old versions to fully comprehend what the messages are talking about. Lastly, you want an integrated log of changes for the project or module as a whole; so learn to maintain ChangeLog files. A bunch of expanded $Log$'s scattered in a file tree is useless compared to a well-maintained ChangeLog. I've worked with people who insisted on $Log$ as a policy; it was frustrating dealing with the merge problems. None of these people understood or performed the merges. If some goofball insists on $Log$, make him do all the merges for a month. ;) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
On Mon, Sep 09, 2002 at 11:17:12AM -0700, Schwenk, Jeanie wrote: After the original import, why do you have to give the full path in the repository to where the imported files are to do? Is it because an import assumes nothing even when there are CVS directories? Correct. An import of a tree with CVS directories is just like an import of one without. (The CVS stuff isn't even a special enough case to get forcibly ignored; as you've noticed, it's just on the default ignore list like *.o etc.) This is reasonable, given the command's name. Even if there is CVS metadata, a command for importing stuff ought not to assume it relates to your repo. E.g. it could be that you checked out an open-source project over the Net, and you're importing the code into your own repo to track your local patches. Just because cvshome.org calls a particular module ccvs doesn't mean you want to use that name :-) import could arguably pay attention to the modules file -- but I'm not going to be the one to argue for it :-) since (a) I don't know what pay attention to would mean in practice, and (b) I rarely use the modules file anyway. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [...] despite reports to the contrary, it is the rare programmer who permanently loses his sanity while coding (permanently being the operative word). - Eric E. Allen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
Eric, At 02:39 PM 9/9/2002 -0400, Eric Siegerman wrote: import could arguably pay attention to the modules file -- but I'm not going to be the one to argue for it :-) since (a) I don't know what pay attention to would mean in practice, and (b) I rarely use the modules file anyway. If you don't use modules file, how do you get the list of modules in the repo w/o going to the repo manually and browsing what folders are there? cvs checkout -c returns just the modules file contents, or not? Stan Berka Stan Berka Programmer Annalyst Portland, OR Pope Talbot (503) 552-4315Fax (503) 2202726 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
Schwenk, Jeanie writes: After the original import, why do you have to give the full path in the repository to where the imported files are to do? Is it because an import assumes nothing even when there are CVS directories? When there are CVS directories where? In the directory you're importing, the repository, or somewhere else? If there are CVS directories in the directory you're importing, and they're from your repository, you should probably be using add rather than import. -Larry Jones I've got to start listening to those quiet, nagging doubts. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: question about importing
This is regarding a vendor branch. When the vendor sends us a new version, we import rather than add. This is per Cederqvist 13.2 Updating with the import command and Chapter 6 Tracking Third-Party Sources: Vendor Branches in Fogel's book. Perhaps I have misunderstood what these two instruct. I thought I had to have the vendor branch checked out. This is wrong? There are CVS directories because we have checked out the latest version vendor code. Over that we unjared the source jars the vendor sent into those very same directories. Then we run 1) the import command, 2) the merge command and 3)the commit command. Since add is not recursive, using add would be error prone not to mention very time consuming. Are we just supposed to unjar the source files into a new directory and run the import command? Jeanie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 12:03 PM To: Schwenk, Jeanie Cc: [EMAIL PROTECTED] Subject: Re: question about importing Schwenk, Jeanie writes: After the original import, why do you have to give the full path in the repository to where the imported files are to do? Is it because an import assumes nothing even when there are CVS directories? When there are CVS directories where? In the directory you're importing, the repository, or somewhere else? If there are CVS directories in the directory you're importing, and they're from your repository, you should probably be using add rather than import. -Larry Jones I've got to start listening to those quiet, nagging doubts. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
On Mon, 9 Sep 2002, Stan Berka wrote: At 02:39 PM 9/9/2002 -0400, Eric Siegerman wrote: import could arguably pay attention to the modules file -- but I'm not going to be the one to argue for it :-) since (a) I don't know what pay attention to would mean in practice, and (b) I rarely use the modules file anyway. If you don't use modules file, how do you get the list of modules in the repo w/o going to the repo manually and browsing what folders are there? Ah, but this is only trivial use of the modules file, since you aren't actually composing modules hierarchically, but only making their names visible. Using modules in any other way will eventually bring harm upon you, for several reasons. The module structure is not versioned as part of your project (of course, the CVSROOT/modules file is subject to version control, but that is not quite the same thing). This is the big problem; if you restructure the project by rearranging the modules file, the change affects the old checkouts, which will conform to the new shape, thereby destroying any notion of configuration management. Other problems: CVS update does not notice changes to the modules file. If you add a sub-module, nobody can pick it up via update; the other users must check out. The wrong pathnames are reported in some situations. For example, try doing a cvs rdiff over a hierarchically composed module. The pathnames in the resulting patch are useless, and so you have a broken patch, one that can only be applied by someone who manually checks out the constitutent modules side by side. cvs checkout -c returns just the modules file contents, or not? That is nearly correct; the contents are subject to some reformatting, which allows for easier parsing of the output. -- Meta-CVS: directory structure versioning; versioned symbolic links; versioned execute permission; versioned property lists; easy branching and merging and third party code tracking; all implemented over the standard CVS command line client -- http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
Schwenk, Jeanie writes: This is regarding a vendor branch. When the vendor sends us a new version, we import rather than add. This is per Cederqvist 13.2 Updating with the import command and Chapter 6 Tracking Third-Party Sources: Vendor Branches in Fogel's book. Perhaps I have misunderstood what these two instruct. I thought I had to have the vendor branch checked out. This is wrong? Yes, it is. You do *NOT* want to have the vendor branch checked out. Are we just supposed to unjar the source files into a new directory and run the import command? Exactly. Importing the second (or third, or fourth, etc.) time is exactly like importing the first time except that you specify a different release tag. You should specify exactly the same repository directory and vendor tag as the first time, and you should import from a new directory, not a CVS working directory. -Larry Jones This sounds suspiciously like one of Dad's plots to build my character. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about importing
On Mon, Sep 09, 2002 at 11:54:14AM -0700, Stan Berka wrote: At 02:39 PM 9/9/2002 -0400, Eric Siegerman wrote: [...] I rarely use the modules file anyway. If you don't use modules file, how do you get the list of modules in the repo w/o going to the repo manually and browsing what folders are there? ls /Repos suits me fine. cvs checkout -c returns just the modules file contents, or not? Pretty much. So I don't consider it very useful. I didn't even know it existed until someone here asked me about it (or rather its GUI equivalent in TortoiseCVS) a week or two ago. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [...] despite reports to the contrary, it is the rare programmer who permanently loses his sanity while coding (permanently being the operative word). - Eric E. Allen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: question about importing
Larry, Thank you for making importing clear. Jeanie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 12:28 PM To: Schwenk, Jeanie Cc: [EMAIL PROTECTED] Subject: Re: question about importing Schwenk, Jeanie writes: This is regarding a vendor branch. When the vendor sends us a new version, we import rather than add. This is per Cederqvist 13.2 Updating with the import command and Chapter 6 Tracking Third-Party Sources: Vendor Branches in Fogel's book. Perhaps I have misunderstood what these two instruct. I thought I had to have the vendor branch checked out. This is wrong? Yes, it is. You do *NOT* want to have the vendor branch checked out. Are we just supposed to unjar the source files into a new directory and run the import command? Exactly. Importing the second (or third, or fourth, etc.) time is exactly like importing the first time except that you specify a different release tag. You should specify exactly the same repository directory and vendor tag as the first time, and you should import from a new directory, not a CVS working directory. -Larry Jones This sounds suspiciously like one of Dad's plots to build my character. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about pserver
Schwenk, Jeanie writes: When on a remote unix host, the successfully logged in user always has to type cvs -d :pserver:generic@pilot:/usr/local/cvs co -c They can't just type cvs co -c? Logging in just associates a password with a CVSROOT specification, it doesn't set your current CVSROOT; you can be logged in to many different CVSROOTs at the same time (I'm currently logged in to 5 or 6). If you've set your $CVSROOT environment variable, you don't need to use -d on the command line (unless you want to override $CVSROOT). -Larry Jones It's either spectacular, unbelievable success, or crushing, hopeless defeat! There is no middle ground! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: question about pserver
Correction ... that would be 2.9 -Original Message- From: Schwenk, Jeanie Sent: Friday, June 14, 2002 5:42 PM To: CVSpost (E-mail) Subject: question about pserver I just want to verify what I've read because it seems wrong. When on a remote unix host, the successfully logged in user always has to type cvs -d :pserver:generic@pilot:/usr/local/cvs co -c They can't just type cvs co -c? Yes, I've read chapter 9. Jeanie __ This is Linux country. On a quiet night, you can hear NT re-boot. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about log command
Andy Kriger writes: I am new to CVS and am trying to get the log command to only output those files changed since a certain date or with a certain revision. When I use the -r or -d flag, the revision information is limited to the flag options, but I still get a header for every file (whether or not it has a relevant revision or change). The most recent release of CVS (1.11.2) adds a -S option to suppress the header when no revisions are selected. -Larry Jones Even my FRIENDS don't do what I want. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
Hi everybody, it's ok for my configuration of WinCVS ! The solution of Larry Jones was the good, it was effectly the / at the end of my CVSROOT in WINCVS which has caused me so much problems... I would like to thank you very much for the help you gave me, and especially Matt for the patience he had with me... Have a good day Nicolas. ** =?iso-8859-1?q?Nicolas=20PEZRON?= writes: so I have configured my inetd.conf file on the server, this is the line I have added to it : #CVS server cvspserver stream tcp nowait root /opt/cvs/bin/cvs cvs -f --allow-root=/cvs/CIDRE/CVSROOT pserver [...] so, I should be able to connect to the server with the user int because I have configured my CVSROOT on my WinCVS client like this : :pserver:int@cidre:/cvs/CIDRE/ The stuff after the last : (/cvs/CIDRE/) must *exactly* match an --allow-root option of the pserver, which it doesn't. I suspect they should both be /cvs/CIDRE (having a trailing slash can cause problems). -Larry Jones I'll be a hulking, surly teen-ager before you know it!! -- Calvin ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
Nicolas PEZRON wrote: finally, I have decided to use WinCVS as a client and a server Unix as a CVS server when I try to connet to the CVS server, I have the following error : cvs login: authorization failed: server cidre rejected access to /cvs/CIDRE/ for user int I don't know how to configure the passwords there is a menu in Admin which is WinCVW and there is a place to put the folder for the passwords I don't know what to put here You need to configure passwords on the server, not the client. See the manual for details: http://www.cvshome.org/docs/manual/cvs_2.html#SEC29 -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
Nicolas PEZRON wrote: so I have configured my inetd.conf file on the server, this is the line I have added to it : #CVS server cvspserver stream tcp nowait root /opt/cvs/bin/cvs cvs -f --allow-root=/cvs/CIDRE/CVSROOT pserver Make sure you have an entry in /etc/services like: cvspserver 2401/tcp I have also created a passwd file in my $CVSROOT/CVSROOT folder, this is my passwd file : int: This looks ok. so, I should be able to connect to the server with the user int because I have configured my CVSROOT on my WinCVS client like this : :pserver:int@cidre:/cvs/CIDRE/ The entry in inetd.conf says that your repository path is /cvs/CIDRE/CVSROOT, while your $CVSROOT is set to /cvs/CIDRE/; they have to be the same. I'm guessing you want to remove the extra CVSROOT from your inetd.conf. Good luck. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
Hi, finally, I have decided to use WinCVS as a client and a server Unix as a CVS server when I try to connet to the CVS server, I have the following error : cvs login: authorization failed: server cidre rejected access to /cvs/CIDRE/ for user int I don't know how to configure the passwords there is a menu in Admin which is WinCVW and there is a place to put the folder for the passwords I don't know what to put here thank you very much for you answer Nicolas. --- Matt Riechers [EMAIL PROTECTED] a écrit : Nicolas PEZRON wrote: may I stock Windows files in my CVS tree on Unix or do I have to use a version of CVS for Windows ? (I tried to see for WinCVS but if I can use CVS on Unix, it will be better for me) If it is easy for you to get at files on the UNIX box from Windows, then you don't necessarily need WinCVS. In that case, you should make sure that your Windows editor doesn't change the file line endings to DOS format. If that's a big problem, you might be better off with using WinCVS. I have also heart about cvs on windows but with a unix cvs server, how does it work ? http://www.cvshome.org/docs/manual/cvs_2.html#SEC26 -Matt ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
when I try to connet to the CVS server, I have the following error : cvs login: authorization failed: server cidre rejected access to /cvs/CIDRE/ for user int You need to configure passwords on the server, not the client. See the manual for details: http://www.cvshome.org/docs/manual/cvs_2.html#SEC29 ok so I have configured my inetd.conf file on the server, this is the line I have added to it : #CVS server cvspserver stream tcp nowait root /opt/cvs/bin/cvs cvs -f --allow-root=/cvs/CIDRE/CVSROOT pserver I have also created a passwd file in my $CVSROOT/CVSROOT folder, this is my passwd file : int: so, I should be able to connect to the server with the user int because I have configured my CVSROOT on my WinCVS client like this : :pserver:int@cidre:/cvs/CIDRE/ but I have always the following message : cvs login: authorization failed: server cidre rejected access to /cvs/CIDRE/ for user int could you help me please, I begin to discourage myself thank you very much and thank you for your previous answers Nicolas. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
=?iso-8859-1?q?Nicolas=20PEZRON?= writes: so I have configured my inetd.conf file on the server, this is the line I have added to it : #CVS server cvspserver stream tcp nowait root /opt/cvs/bin/cvs cvs -f --allow-root=/cvs/CIDRE/CVSROOT pserver [...] so, I should be able to connect to the server with the user int because I have configured my CVSROOT on my WinCVS client like this : :pserver:int@cidre:/cvs/CIDRE/ The stuff after the last : (/cvs/CIDRE/) must *exactly* match an --allow-root option of the pserver, which it doesn't. I suspect they should both be /cvs/CIDRE (having a trailing slash can cause problems). -Larry Jones I'll be a hulking, surly teen-ager before you know it!! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVS on Windows NT
Nicolas PEZRON wrote: may I stock Windows files in my CVS tree on Unix or do I have to use a version of CVS for Windows ? (I tried to see for WinCVS but if I can use CVS on Unix, it will be better for me) If it is easy for you to get at files on the UNIX box from Windows, then you don't necessarily need WinCVS. In that case, you should make sure that your Windows editor doesn't change the file line endings to DOS format. If that's a big problem, you might be better off with using WinCVS. I have also heart about cvs on windows but with a unix cvs server, how does it work ? http://www.cvshome.org/docs/manual/cvs_2.html#SEC26 -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on multiple repositories
On Thu, 4 Apr 2002, Max wrote: Date: Thu, 04 Apr 2002 01:23:18 GMT From: Max [EMAIL PROTECTED] To: [EMAIL PROTECTED] Newsgroups: gnu.cvs.help Subject: [info-cvs] Question on multiple repositories I'm brand new at the CVS game and have no senior resource available at work, so I'm hoping that I can get some help here. The specs I was handed at the office call for an open development repository and a secure QA/production repository. This is nonsense; everyone can work from the same repository. Once developers finish their stuff, a baseline is made and the code is replicated to the QA repository. This is the step where I'm having a problem. CVS can assign a symbolic revision to the baseline. This is done using cvs rtag. A branch can be made from the symbolic revision when critical bugs need to be fixed in a build that is identified as a release candidate. So no separate repository is needed to stabilize code. If you really want a stable second level repository, simply use CVS's import feature to import snapshots on the vendor branch. That is, treat the devoper team as a third-party source code ``vendor''. which at this time is empty. I set my CVSROOT to point the development, check out based on a tag, then try get the code into the QA repository. First I set my CVSROOT to point to the QA repository, then use commit to move the code. Alternatively, since there are no modules in the QA repository, I try to use add. Both fail because I still appear to be pointing to the development repository. I'm hesitant to use import because (as I understand it) this command will club the previous versions under the same name (down the road). No, import does not club anything, it adds new versions. So the question I have is how do I move source from one repository to the other? Is there a way to save the baseline and the version numbers in the process. Not without copying the RCS files themselves, which simply gives you an exact replica of the repository, not a different repository that contains only the stable baselines you want. -- Meta-CVS: solid version control tool with directory structure versioning. http://users.footprints.net/~kaz/mcvs.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question on multiple repositories
Hi Max, CVS stores metadata about the current repository in the sandbox; notice that there are subdirs named CVS/ in every CVS-controlled directory. You can't just change your CVSROOT, since revision numbers and other important metadata will be incorrect, since the state of your sandbox is stored on the client side. You either need - 1) two seperate checkouts, and copy the files between these two checkouts. 2) branches ( see http://www.cvshome.org/docs/manual/cvs_5.html#SEC54 ) I recommend branches. Either way should work fine, but there's really no good reason to have seperate repositories, it's alot more work that you have to do ( which means more potential for human error :P ). HTH, Rob On Thu, Apr 04, 2002 at 01:23:18AM +, Max wrote: I'm brand new at the CVS game and have no senior resource available at work, so I'm hoping that I can get some help here. The specs I was handed at the office call for an open development repository and a secure QA/production repository. Once developers finish their stuff, a baseline is made and the code is replicated to the QA repository. This is the step where I'm having a problem. I have the development repository up and running and made a QA repository, which at this time is empty. I set my CVSROOT to point the development, check out based on a tag, then try get the code into the QA repository. First I set my CVSROOT to point to the QA repository, then use commit to move the code. Alternatively, since there are no modules in the QA repository, I try to use add. Both fail because I still appear to be pointing to the development repository. I'm hesitant to use import because (as I understand it) this command will club the previous versions under the same name (down the road). So the question I have is how do I move source from one repository to the other? Is there a way to save the baseline and the version numbers in the process. Any help would be greatly appreciated. Max ___ 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: Question on multiple repositories
In aWNq8.14247$[EMAIL PROTECTED] Max [EMAIL PROTECTED] writes: I'm brand new at the CVS game and have no senior resource available at work, so I'm hoping that I can get some help here. The specs I was handed at the office call for an open development repository and a secure QA/production repository. Once developers finish their stuff, a baseline is made and the code is replicated to the QA repository. This is the step where I'm having a problem. Complicated. Call it a formal release from dev to QA: cvs export from dev, cvs import in QA. At the same time, dev creates a bugfix branch and checks out a sandbox on it. When QA fixes a bug, it sends a patch to dev, who applies it to the bugfix sandbox, commits, and merges back to the trunk. I'm hesitant to use import because (as I understand it) this command will club the previous versions under the same name (down the road). That's what you have to do, though. The QA people will just have to learn how to do pre-import tags and post-import merges. It's a lot more trouble for them too, but those are the consequences of the rules imposed on you. Note that an import doesn't destroy previous imports. It can break the trunk until the post-import merge is finished, but past imports are always available through their tags. Faint glimmer of hope: what do they mean by secure QA? If secure really means secure, you're in the import/export business and that's that. If secure only means commits to QA tress are restricted, then you *might* get away with commitinfo scripts that reject commits by developers when on a QA branch. Understand that this is not secure at all, in that a developer determined to break company rules can probably defeat the system. It will only prevent casual or inadvertent commits. If acceptable, this would be *much* better for all: a single repository, dev releases to QA simply by creating a tag, QA creates and manages the bugfix branch, dev merges directly from the branch to the trunk. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about commits in CVSROOT and running loginfo scripts
--- Mark [EMAIL PROTECTED] wrote: When I tryed to have a loginfo script read the writers file, it seems that the administrative database isn't really rebuilt till after the loginfo scripts have completed runing. The writers file read by the loginfo script always sees a writers file without the changes I just commitied. (The loginfo script was reading the actual writers file in the repository). I had to have it use the workarea copy to read the accurate contents. Is this the correct operation of the admin files in CVSROOT on commits? Since loginfo scripts (or at least loginfo itself) are CVSROOT files themselves, it makes sense that CVSROOT files are updated after loginfo scripts execute. Is this the same with all other files in CVS? One thing that has cause issues for me is that it seems cvs maintains locks after a commit while the loginfo scripts are running (I had found out about these lock issues trying to add to the commited file's log message in a loginfo script). I had to fork the script and exit the parent to get cvs to release the lock, though I am not sure what is really happening or what I really did to get things working. Can anyone elaborate on how cvs deals with locks after a commit and into the running of loginfo scripts? If you do this, you introduce a race condition. For example, more than one loginfo script may now be executing. If you need to use CVS commands within loginfo, try either using RCS commands, or create a temporary module who's archive files are symlinked to the real module's archive files. Do not fork unless you're positive race conditions won't affect you. Noel __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about commits in CVSROOT and running loginfo scripts
Noel Yap writes: If you need to use CVS commands within loginfo, try either using RCS commands, or create a temporary module who's archive files are symlinked to the real module's archive files. Do not fork unless you're positive race conditions won't affect you. In most cases, you can use CVS commands with the global -n option (no execute) to ignore locks. That's a much better method than either of the above. -Larry Jones Oh, now don't YOU start on me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about commits in CVSROOT and running loginfo scripts
--- Larry Jones [EMAIL PROTECTED] wrote: Noel Yap writes: If you need to use CVS commands within loginfo, try either using RCS commands, or create a temporary module who's archive files are symlinked to the real module's archive files. Do not fork unless you're positive race conditions won't affect you. In most cases, you can use CVS commands with the global -n option (no execute) to ignore locks. That's a much better method than either of the above. If cvs -n is used, then how is the loginfo script suppose to modify the log message of the commited file? __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about commits in CVSROOT and running loginfo scripts
Mark writes: If cvs -n is used, then how is the loginfo script suppose to modify the log message of the commited file? The loginfo script isn't supposed to modify the log message. What in the world are you trying to do? -Larry Jones I think your train of thought is a runaway. -- Calvin's Mom ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question
Kenny wrote: I have one project it has about 1200 source files. can I use CVS to track by the file instead of the project. So that I can only checkout one file. I'm not sure I understand your question. You can checkout individual files from a repository with: cvs co path/to/file Is that what you are asking? -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question
Well that means creating 1200 projects. CVS goes by project / module which consists of multiple files. Better create a single project and to checkout only one file use cvs co project/dirpath/filename Regards, Vishal Jain -Original Message- From: Kenny [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 11:29 AM To: [EMAIL PROTECTED] Subject: Question I have one project it has about 1200 source files. can I use CVS to track by the file instead of the project. So that I can only checkout one file. Thanks = __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ 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: question regarding diffing tags and branches..
Mark Lancisi writes: I need to find out the list of changes, per file, made to a branch since = its creation. cvs log -r branch I also need a list of changes, per file made to the trunk = since creation of the branch. I want to be able to sort these lists of = files and compare them. I've got a static tag signifying the foot of the branch. Does anyone = have any tips on the easiest way to get this info out of cvs? cvs log -r branch_base: -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about CVSROOT/taginfo file
Miguel Angel Cuadrado wrote: I have modified the CVSROOT/taginfo file in order to execute a script when an user make a TAG. ... If I do a tag in a directory that contains 3000 files, the server aborts the action and returns 'Argument list too long' Your shell is choking on the argument list. What shell are you using? Using that shell interactively, go to the directory in question and run 'ls *', and you'll see the same message. Try a different shell, if possible. A better solution would be to reorganize your directories, and perhaps your build system. Performance may be seriously degraded (depending on the filesystem) when you have that many files in a directory, and those files most likely shouldn't be managed under CVS to begin with. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question about CVSROOT/taginfo file
I have modified the CVSROOT/taginfo file in order to execute a script when an user make a TAG. CVS invoques this script whit these arguments: $1 -- tagname $2 -- operation add for tag, mov for tag -F ... $3 -- repository $4- file revision [file revision ...]$1, $2, $3, $4 If I do a tag in a directory that contains 3000 files, the server aborts the action and returns 'Argument list too long' How can I resolve that? (My script does´t need the 4th argument) Thanks for your help. Miguel. Miguel, I reported this same problem in August 1999. cvs rtag: cannot exec /usr/local/cvsroot/CVSROOT/taginfo_filter: Arg list too long cvs rtag: Pre-tag check failed cvs [rtag aborted]: correct the above errors first! Pierre Asselin, Westminster, Colorado posted a reply saying: That's a bug in the design. Long arguments should be passed to scripts on standard input, as is done for loginfo. This would be an incompatible change to taginfo so we need a back-compatibility kludge. Maybe something like this? == taginfo == DEFAULT /usr/local/cvsroot/CVSROOT/old_script DEFAULT -stdin /usr/local/cvsroot/CVSROOT/new_script the `-stdin' option causes the FILENAME, REVISION pairs to be sent to the script's standard input (recommended); without the option, the FILENAME, REVISION pairs are appended to the command line (deprecated). I agree that it is a bug in the design! The -stdin approach would work for me. I also received mail about the Arg list too long being a limitation of the shell. They suggested as a workaround installing one of the open source shells (bash/tcsh) as the standard shell. They are not limited in this way. This suggestion is incorrect! I am using a SGI and the ncargs system tuning value is set for 20480. The man page for tcsh talks about the Arg list too long problem and suggest increasing the ncargs to a higher value using systune. I would need to increase it above 48000 to handle the current list. In time that would not be enough. For now I have turned my taginfo_filter off because of the problem. taginfo actually calls the program for each directory that is tagging. My taginfo_filter worked fine until it hit a subdirectory that had the Arg list too long problem. Because of this it writes to the log file for each directory. I wished it only called it once but that is another topic. Dale Miller ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question: How to ignore generate files when we do cvs update
http://www.cvshome.org/docs/manual/cvs_18.html#SEC173 This section spells out exactly what you want to do. donald On Thu, Feb 07, 2002 at 03:33:15PM -0600, Tom Choi wrote: All, We have several generate files and never commit them to our CVSROOT. When we did cvs update. And then I saw ? for generate files. Would you tell me how to ignore generate files when we do cvs update? Thanks, Tom ___ 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: Question: How to ignore generate files when we do cvs update
Tom Choi writes: Would you tell me how to ignore generate files when we do cvs update? http://www.cvshome.org/docs/manual/cvs_18.html#SEC173 -Larry Jones Somebody's always running my life. I never get to do what I want to do. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question: How to ignore generate files when we do cvs update
Tom Choi wrote: We have several generate files and never commit them to our CVSROOT. When we did cvs update. And then I saw ? for generate files. Would you tell me how to ignore generate files when we do cvs update? cvsignore: http://www.cvshome.org/docs/manual/cvs_18.html#SEC173 -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question: How to remove a directory
Tom Choi writes: Would you tell me how to remove a directory? I have a CVS tree with a top delta and several branches. Only I want to remove a directory from a top delta, nothing from branches. CVS only manages files, not directories. As far as CVS is concerned, directories are just things that hold files. If you checkout/update with the -P option (which you generally should -- you may want to add it to your ~/.cvsrc file if you haven't already), directories that don't contain any files will be deleted. -Larry Jones It's going to be a long year. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about tag
On Thu, Jan 24, 2002 at 02:39:52PM +, Colm Murphy wrote: So I try cvs tag TAG Module from the top of the sandbox. No joy. I get the following: cvs tag: cannot open CVS/Entries for reading: No such file or directory cvs [tag aborted]: no repository Don't do it from above your sandbox. Instead: cd Module cvs tag TAG Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question about tag
Hi Steve, Unfortunately this will only work for simple modules. If you have alias modules containing files from different directories, and/or certain (but not all) files in a directory then this won't work. I assumed that since the modules were alias type cvs tag Module would be the same as typing cvs tag file1 file2 file3 etc. (which does work) Colm A Steve Greenland wrote: On Thu, Jan 24, 2002 at 02:39:52PM +, Colm Murphy wrote: So I try cvs tag TAG Module from the top of the sandbox. No joy. I get the following: cvs tag: cannot open CVS/Entries for reading: No such file or directory cvs [tag aborted]: no repository Don't do it from above your sandbox. Instead: cd Module cvs tag TAG Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question sharing modules
First, create a common project that has all of the source modules from both projects. Then, in the modules file, define two new projects, each with only the files from the common project which they need. Unfortunately, this means that your name-space cannot overlap between the files that are NOT shared. This is only one way of accomplishing what you want - in general, using the modules file in CVSROOT of the repository is the suggested way of having variations of projects that include different sets of files from a single common project. Hope this helps - Allen Jensen - Original Message - From: Dennis Jarosch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 15, 2002 6:23 PM Subject: Question sharing modules Hi!! I'm new to CVS, in fact I just installed it today. How do I share modules between projects? What I am trying to do is share common files between 2 projects and I want all 3 in CVS. The problem is setting the project-modules up so they'll use the common files module in CVS, so when I change files from that module in one of the other mods, the CVS common files module will automatically be updated. Is there a way to do this? Thanks very much!! Dennis ___ 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: Question - commiting modified file
On Wed, Jan 09, 2002 at 11:00:09AM -0800, Anjali Madhekar wrote: When I generate some files during the build, they appear as 'modified' in CVS. when I do a 'diff' the exit status is '0' indicating that the files are indentical. [Channelling GW] Why on earth are you storing generated files in CVS? 1. Do they have 'modified' status due to the file creation time stamp? I've never seen CVS do this. Are you perhaps using WinCVS? 2. Out of 20-30 files that are generated, some may actually be different. So how do I checkin only those that changed? Check in all of them. CVS will actually only work on those that have changed. As you yourself note. 3. After doing a 'commit' on a file that appears modified but is identical, CVS does not check in that file. But the file continues to appear as 'modified'. How can I get it to show the status as current? Again, I think you must be using WinCVS. Just do an update on the directory. But your primary problem is that you're storing non-source files in CVS, which is *wrong*. Bad. Unwise. Pretty much any other negative adjective you care to think of. Don't do it, and you'll be happier. Steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question - commiting modified file
When I generate some files during the build, they appear as 'modified' in CVS. when I do a 'diff' the exit status is '0' indicating that the files are indentical. 1. Do they have 'modified' status due to the file creation time stamp? Yes. 3. After doing a 'commit' on a file that appears modified but is identical, CVS does not check in that file. But the file continues to appear as 'modified'. How can I get it to show the status as current? doing an 'update' will sort things out. You should always do an update before a commit to make sure you are in sync with the repository failing to do so leads to madness and in multiperson projects always some amount of pain. Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question - commiting modified file
Anjali Madhekar writes: When I generate some files during the build, they appear as 'modified' in CVS. when I do a 'diff' the exit status is '0' indicating that the files are indentical. 1. Do they have 'modified' status due to the file creation time stamp? Yes (although it's actually the modification time stamp). 2. Out of 20-30 files that are generated, some may actually be different. So how do I checkin only those that changed? Is there some thing like a force checkin which allows me to checkin all files with the updated comment? (Though the file appears 'modified' CVS does not seem to commit it if it is actually an identical file, is this correct?) Correct -- if you do a general commit, CVS will check the files that may have been modified to see if they were actually modified and only commit those that were actually modified. Usually, that also corrects the status, but doing an update or status will also correct the displayed status. -Larry Jones It's SUSIE! It's a GIRL! Santa would understand! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Question - commiting modified file
On Wed, Jan 09, 2002 at 11:00:09AM -0800, Anjali Madhekar wrote: When I generate some files during the build, they appear as 'modified' in CVS. when I do a 'diff' the exit status is '0' indicating that the files are indentical. 1. Do they have 'modified' status due to the file creation time stamp? (I'm not sure about this - grains of salt recommended): Could be. Probably depends on what CVS client you are using. Which CVS client are you using? 2. Out of 20-30 files that are generated, some may actually be different. So how do I checkin only those that changed? Is there some thing like a force checkin which allows me to checkin all files with the updated comment? (Though the file appears 'modified' CVS does not seem to commit it if it is actually an identical file, is this correct?) I believe it is. But you can *force* a commit with cvs commit -f 3. After doing a 'commit' on a file that appears modified but is identical, CVS does not check in that file. But the file continues to appear as 'modified'. How can I get it to show the status as current? (grains of salt again): Sounds like your CVS client is looking at the timestamp. Which client? Thanks, Anjali -- Karl E. Jørgensen [EMAIL PROTECTED] www.karl.jorgensen.com /\ \ / ASCII Ribbon Campaign x - Say NO to HTML in email / \ - Say NO to Word documents in email (and Macros!) msg16028/pgp0.pgp Description: PGP signature
Re: question on cvs update
Naveen Srinivasa Murthy writes: Since the new sub-directory and its contents are not in my local machine , I presumed that i should be doing a 'cvs update' to download the new directory and its contents. You need to use update -d to create new directories. -Larry Jones It's either spectacular, unbelievable success, or crushing, hopeless defeat! There is no middle ground! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about cvsignore
My local respository is in /usr/local/cvsroot. I went into my working area and issued... cvs -d /usr/local/cvsroot/ co CVSROOT ... I then changed into the new working area subdirectory of CVSROOT and issued... echo *.class *.txt *.jar cvsignore cvs add cvsignore cvs commit -m New file cvsignore ...and things are added into the repository as expected. Does that help? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about cvsignore
[EMAIL PROTECTED] (Larry Jones) wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] writes: currently, my $CVSROOT/CVSROOT dir does not contains a cvsignore file. Is it sufficient to simply create the file in the directory, or do I need to checkout CVSROOT, and 'cvs add' the cvsignore file? Simply creating the file is sufficient, but checkout and add is more correct. I have the same problem too: $CVSROOT/CVSROOT/cvsignore doesn't work. Here is my previous posting: ,- | I am having problems trying to avoid some files using cvsignore file. | When I created it using the following command, | | echo *.class *.txt *.jar $CVSROOT/CVSROOT/cvsignore | chmod ug+rwx,o-rwx !$ | | and did a cvs import (using a normal user account), all .class files | get imported. Here is part of the output: | | N .../tests/DBSecurityMatrixTests.java | N .../tests/DBSecurityMatrixTests.class | | When I set the CVSIGNORE intead, | | export CVSIGNORE=*.class *.txt *.jar | | The .class files get correctly ignored. (I saw:) | | I .../tests/DBSecurityMatrixTests.class | | What's wrong? Both my root and normal user have the same CVSROOT | setting. Besides, I set | | export CVSREAD=yes | | in my client env. | | Please help. Thanks `- I've been searching through news archive for the answer. It seems to be the most frequently asked question, with no correct answer yet. Here is what happened when I tried to checkout CVSROOT, and 'cvs add' the cvsignore file: /export/cvs/CVSROOT# cvs add cvsignore cvs add: in directory .: cvs [add aborted]: there is no version here; do 'cvs checkout' first /export/cvs/CVSROOT# cvs checkout . cvs [checkout aborted]: Cannot check out files into the repository itself /export/cvs/CVSROOT# cvs checkout cvsignore cvs [checkout aborted]: Cannot check out files into the repository itself ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: question about Permission denied
Thanks for you advice Larry, I do not have -f global option in /etc/inetd.conf but I don't think that is my problem. More info: I have 2 linux 6.1 boxes, both installed with CVS 1.10.6 I was using one to let people connect to and use CVS, the other was a backup machine incase the other crapped out. I tar/gzip/ftp file from one to the other on some frequent basis. the 2 machines are not identical, one has more disk space. I have a new project that I need the more disk space, this is the machine that I get the Permission denied on. I do not see the difference in permissions or in the inetd.conf file between these 2 machines. one lets me check out and the other don't. initd.conf of working box: cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/local/CVS pserver initd.conf of NON working box: cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/local/CVS pserver Neither contained the -f option, I think this is where you meant is would be seen? ls -al at /usr/local on working box drwxrwxr-x 11 root cvs 1024 Oct 8 15:10 CVS ls -al at /usr/local on NON working box /usr/local drwxrwxr-x 5 root cvs 4096 Nov 29 18:43 CVS - ls -al at /usr/local/CVS on NON working box drwxrwxr-x 10 deaverc cvs 4096 Nov 29 19:16 rmcqh all files in this dir and all sub dirs have drwxrwxr-x permissions, most owned by deaverc:cvs CVSROOT is owned by root:cvs drwxrwxr-x 2 root cvs 4096 Nov 29 18:32 CVSROOT I use wincvs to access these repositories. I was able to Import several modules, I look on the linux box and all I imported is there, but when I got to checkout a module is when I get the permission denied problem. What else can I look at that may be causing the problem? I do not think it would be a bad inetd.conf, since I am able to check modules in to CVS just fine, that lets me know CVS is up and running. I am also able to issue cvs -v and get response. The -f option sounded promising especially when I saw I did not have it on the command for cvspserver, but then when I see the machine that is working and it also does not have it, I don't think that is going to be my problem? Carl Deaver -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 10:08 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: question about Permission denied Deaver, Carl writes: cvs -z9 checkout -P rmcqh (in directory C:\ccc) cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied Either you forgot the -f global option in /etc/inetd.conf or you've got a defective inetd and you're not running the latest release of CVS (1.11.1p1), which you can get from http://www.cvshome.org, should you need it. -Larry Jones ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about Permission denied
Deaver, Carl writes: I do not have -f global option in /etc/inetd.conf but I don't think that is my problem. It is. You're only seeing it on one machine because the permissions on /root are different on the two machines (the machine with the problem has the preferred permissions). initd.conf of NON working box: cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/local/CVS pserver Neither contained the -f option, I think this is where you meant is would be seen? Yes -- right before the --allow-root. Also note that CVS 1.10.6 is pretty old -- I suggest upgrading to the current release (1.11.1p1), which you can get from www.cvshome.org. -Larry Jones Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about cvsignore
[EMAIL PROTECTED] writes: currently, my $CVSROOT/CVSROOT dir does not contains a cvsignore file. Is it sufficient to simply create the file in the directory, or do I need to checkout CVSROOT, and 'cvs add' the cvsignore file? Simply creating the file is sufficient, but checkout and add is more correct. Also, will listing directory names in cvsignore work? ie, can I put 'debug' and 'release' in cvsignore, to ignore my build directories? Maybe -- try it and see. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about Permission denied
Deaver, Carl writes: cvs -z9 checkout -P rmcqh (in directory C:\ccc) cvs server: cannot open /root/.cvsignore: Permission denied cvs [server aborted]: can't chdir(/root): Permission denied Either you forgot the -f global option in /etc/inetd.conf or you've got a defective inetd and you're not running the latest release of CVS (1.11.1p1), which you can get from http://www.cvshome.org, should you need it. -Larry Jones But Mom, frogs are our FRIENDS! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
