Newbie question
Hello everyone! I am trying to install CVS. Before starting I want to check few things and hopefully U guys have answers. My questions are: 1. CVS (linux) vs CVSNT (windows) - Which one is better performance wise, stability and reliability wise? As I haven't started the project yet, I can go either way. Please suggest me which is better to use or if it makes no difference. 2. What are system requirements on which we install CVS server? Any advice/suggestion are greatly appreciated. Thank you. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Newbie question
Madhavi Thottempudi wrote: Hello everyone! I am trying to install CVS. Before starting I want to check few things and hopefully U guys have answers. My questions are: 1. CVS (linux) vs CVSNT (windows) - Which one is better performance wise, stability and reliability wise? As I haven't started the project yet, I can go either way. Please suggest me which is better to use or if it makes no difference. I believe prior messages on the list have indicated that if you are doing some dev on Unix and some dev on MS, having the server on Unix is the better option. I suggest you search the list[1] about unix vs windows server. as for CVS vs CVSNT (which can also be installed on Unix), if you will not be using any of the extended features CVSNT offers, CVS comes with most linux distributions and is probably already installed so you can just begin using it. 2. What are system requirements on which we install CVS server? manual section 2.9.1, Server requirements [2] [1] http://lists.gnu.org/archive/html/info-cvs/ [2] https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC27 -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Newbie question
Just looking at the two mailing list - cvsnt and info-cvs I can see lot more people in distressed about CVSNT stability. And I am biased against Windows as a stable platform compared to Linux. Many of the 3rd party/commercial tools are better supported on CVS than CVSNT imho. Peformance wise many people here have noted CVS on Linux being faster than CVSNT. Unless you are a Windows shops and need integration with Microsoft's authentication infrastructure stick with real CVS. System requirements - A Linux box with 1GB physical RAM and SWAP will be plenty good. It depends on how many users and size of your files/repoz. Madhavi Thottempudi wrote: Hello everyone! I am trying to install CVS. Before starting I want to check few things and hopefully U guys have answers. My questions are: 1. CVS (linux) vs CVSNT (windows) - Which one is better performance wise, stability and reliability wise? As I haven't started the project yet, I can go either way. Please suggest me which is better to use or if it makes no difference. 2. What are system requirements on which we install CVS server? Any advice/suggestion are greatly appreciated. Thank you. ___ 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
newbie question
Hi, I used wincvs to update the opencv source on my winndows machine. Wincvs exited with code 0 , success.While the cvs was checking for now new updates...it displayed cvs checkout: Updating opencv/cv/src But when i checked the files in the folder they are the same. What wrong am i doing.? My other question is how do i rebuild the files that have been updated on a windows machine. PLease help thanks Jay ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Tag/branch question
I've got some difficulty in understanding how to tag dead revisions such that branch merges will work. Consider this: Initial state (version, tag): 1.3 LAST_MERGED 1.4 REL_1 Now merge on some branch: cd branch... cvs up -j LAST_MERGED -j REL_1 cvs rtag -F -r REL_1 LAST_MERGED I get on trunk: 1.3 1.4 REL_1, LAST_MERGED Ok. Now delete the file, commit: cvs rm -f file cvs ci 1.3 1.4 REL_1, LAST_MERGED 1.5 dead How would I have to create tag REL_2 so that a following cvs up -j LAST_MERGED -j REL_2 will delete the file on the branch as well? Obviously, the tags need to be something like 1.3 1.4 REL_1, LAST_MERGED 1.5 REL_2, dead but how to get REL_2 onto the dead rev? cvs tag ... in the sandbox won't find the file anymore. Thanks, Michael ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
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
Question about CVS-SSH
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. 2) then I generate public key authentication for the cvs account by ssh-keygen -b 2048 -t dsa 3) copy /root/.ssh/id_dsa.pub into the directory /home/cvs/.ssh2 4) generate .ssh2/authorization, and put the following two lines into the file: key id_dsa.pub Options command=/usr/bin/cvs server,no-x11-forwarding At the remote workstation with Debian Linux system, I did the following: 1) in .cshrc, add the following two lines setenv CVS_RSH ssh setenv CVSROOT :ext:[EMAIL PROTECTED]:/home/cvs 2) Copy id_dsa.pub from the server and put it in the .ssh2 directory. 3) echo idkey id_dsa ~/.ssh2/identification 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 Please help what I was doing wrong in the above steps, and please give me more suggestions if possible, many thanks. Huaer ___ 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
Question about directory re-use (cvs status error)
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: newbie question : regarding installation
Title: Message Michael, CVS on Server to use on Windows is most usually CVSNT: http://www.cvsnt.org/ CVSNT is the default client included with WinCVS and TortoiseCVS - which are both excellent graphical front ends. The mailing list for CVSNT is here: 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 Michael EchavezSent: Monday, 6 June 2005 1:38 AMTo: cvsSubject: newbie question : regarding installationHi everyone,Greetings!I was thinking of using cvs for one of my projects. And i was wondering if any of you got an advice as to how i would install cvs for windows xp. There's a lot of web sites that recommend different approaches in doing so. Since most of them differ in the software (i.e., cvsnt, putty, cgywin) involved in installing cvs, i get confused with which is the best one to use. If you could recommend or suggest anything, I would really really appreciate it.Thank you and Good day!Regards,Michael ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Sorry about this newby question
Jim wrote: Ah, I didn't understand the part about the attic. I'm trying to build a system that will still work when the server is off-line. I'll have to scratch my head about that one. No doubt I did the init by mistake. Before I did it, it adding caused it to yell at me about CVSROOT and after it did not yell, so it seemed right to me, but as I said, I'm new. Thank you. Jim You might be interested in the following threads: http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00191.html http://lists.gnu.org/archive/html/info-cvs/2004-11/msg00213.html http://lists.gnu.org/archive/html/info-cvs/2005-01/msg00244.html I would suggest consulting with Greg A. Woods to find out if he has began implementation, or has a coherent set (not spread across several emails) of specifications for the changes suggested in the above links. Also be aware the request in 2004-11/msg00191 for the ability to do the add -C thing, i.e., don't make it impossible. Over all I think this, removing cvs add's need to contact the server, is the FIRST step in giving cvs an off-line mode. (yes that means I have been thinking about it, but have not implemented anything.) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Sorry about this newby question
Jim wrote: Hello, Coming back to re-read your original post ... I note some possible confusion. I apologize in advance for what is no doubt a foolish question, but I'd greatly appreciate it if a kind soul could set me straight. I've just checked out a CVS archive (I have Fedora Core 1 running on a laptop, if that matters). export CVSROOT=/usr/local/cvs mkdir $CVSROOT cd $CVSROOT cvs init You have just made a local (to your machine) cvs repository. cvs -d:pserver:[EMAIL PROTECTED] login cvs -z3 -d:pserver:[EMAIL PROTECTED] co modulename Now you try to checkout a module from another site INTO your repository. This is wrong!!!. There are two ways I can think of to do what I THINK you are attempting to do: 1) use a product like cvsup[1] to mirror the repository you want 2) do the checkout from the remote machine some where else and either convince cvs to ignore the CVS directories, or remove the CVS directories, and either import or add all the files into your local repository. method 1 may be easier to do and keep sanely synchronized, but if it (and I have not read the cvsup pages) requires a special program on the server you may be stuck with method 2. (I pasted in the instructions that were on the site, so I'm pretty sure I did it right.) Now I want to add a file to the local repository (by that I mean the sandbox). But I am on a laptop, not connected to the Internet. cd modulename cp /home/jim/newfilename . cvs add newfilename and the system objects unknown host ... (it names the host from which I checked out the material). This is because you have confused cvs by doing a checkout from an external repository into your local one. You should never do a checkout inside of the repository. [1] http://www.cvsup.org/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
newbie question : regarding installation
Hi everyone, Greetings! I was thinking of using cvs for one of my projects. And i was wondering if any of you got an advice as to how i would install cvs for windows xp. There's a lot of web sites that recommend different approaches in doing so. Since most of them differ in the software (i.e., cvsnt, putty, cgywin) involved in installing cvs, i get confused with which is the best one to use. If you could recommend or suggest anything, I would really really appreciate it. Thank you and Good day! Regards, Michael ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: newbie question : regarding installation
Hi The preferred way of installing CVS is serving the repository from a Unix/Linux server (w/o shell access) and on the windows client side using the :pserver method and using 1 of the 3 following clients to login: 1. DOS client (cvs.exe) [Very easy 3-step set up] 2. Tortoise, A seamless Windows Explorer plugin 3. WinCVS, a GUI and complete API However, if you plan to serve CVS from a *nix server and give shell access to users, then they could use putty.exe to access the *nix server from their WinXP desktops but this means their working folders views will be on the *nix box and not their desktops. If you're not planning to serve CVS from unix/linux then you need to CVSNT and serve it from a Windows Server and again use one of the above clients to login. If you don't serve the repository from a server (unix or nt) then it will be local ONLY to your machine and others will not get to see it. And I don't think you'd wanna install cvsnt on your XP desktop to allow your machine to be choked acting as a server. I hope this is clear enough to get you going and if I'm wrong, I'm sure someone will correct me. :) Steven Original Message Follows From: Michael Echavez [EMAIL PROTECTED] Reply-To: Michael Echavez [EMAIL PROTECTED] To: cvs info-cvs@gnu.org Subject: newbie question : regarding installation Date: Sun, 5 Jun 2005 23:38:14 +0800 MIME-Version: 1.0 Received: from lists.gnu.org ([199.232.76.165]) by mc2-f9.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Jun 2005 08:42:41 -0700 Received: from localhost ([127.0.0.1] helo=lists.gnu.org)by lists.gnu.org with esmtp (Exim 4.43)id 1DexJW-0008CZ-WEfor [EMAIL PROTECTED]; Sun, 05 Jun 2005 11:45:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)id 1DexIh-0008B8-8Tfor info-cvs@gnu.org; Sun, 05 Jun 2005 11:44:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)id 1DexIf-0008AC-FEfor info-cvs@gnu.org; Sun, 05 Jun 2005 11:44:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org)by lists.gnu.org with esmtp (Exim 4.43) id 1DexIf-000899-BAfor info-cvs@gnu.org; Sun, 05 Jun 2005 11:44:33 -0400 Received: from [64.233.184.206] (helo=wproxy.gmail.com)by monty-python.gnu.org with esmtp (Exim 4.34) id 1DexFU-0005ZM-K7for info-cvs@gnu.org; Sun, 05 Jun 2005 11:41:16 -0400 Received: by wproxy.gmail.com with SMTP id 50so2444026wrifor info-cvs@gnu.org; Sun, 05 Jun 2005 08:38:14 -0700 (PDT) Received: by 10.54.115.3 with SMTP id n3mr2636714wrc;Sun, 05 Jun 2005 08:38:14 -0700 (PDT) Received: by 10.54.24.42 with HTTP; Sun, 5 Jun 2005 08:38:14 -0700 (PDT) X-Message-Info: JGTYoYF78jFhIxYbmFAGbyIpB4oaDQ46FEi88Fe29DY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type;b=SEHdIlidgQGKq5YUHA0B7v5j7mBFEJDHiycYOz7qOy1coTPFh2fy+L/Wnys9a/BXq0RuDpX4Jr3O6xhshHsDoIHF0QJgPagwa/+F216/7aclLZXfT2CLpYWZb3E2NokFOcSEE6Jq/A95+j+rCOybWJ8VhO/XhdY9wKkOuoXnyJM= X-BeenThere: info-cvs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Announcements and discussions for the CVS version control systeminfo-cvs.gnu.org List-Unsubscribe: http://lists.gnu.org/mailman/listinfo/info-cvs,mailto:[EMAIL PROTECTED] List-Archive: http://lists.gnu.org/pipermail/info-cvs List-Post: mailto:info-cvs@gnu.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.gnu.org/mailman/listinfo/info-cvs,mailto:[EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 05 Jun 2005 15:42:41.0837 (UTC) FILETIME=[35A525D0:01C569E5] Hi everyone, Greetings! I was thinking of using cvs for one of my projects. And i was wondering if any of you got an advice as to how i would install cvs for windows xp. There's a lot of web sites that recommend different approaches in doing so. Since most of them differ in the software (i.e., cvsnt, putty, cgywin) involved in installing cvs, i get confused with which is the best one to use. If you could recommend or suggest anything, I would really really appreciate it. Thank you and Good day! Regards, Michael ___ 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: Sorry about this newby question
Ah, I didn't understand the part about the attic. I'm trying to build a system that will still work when the server is off-line. I'll have to scratch my head about that one. No doubt I did the init by mistake. Before I did it, it adding caused it to yell at me about CVSROOT and after it did not yell, so it seemed right to me, but as I said, I'm new. Thank you. Jim ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Sorry about this newby question
Hello, I apologize in advance for what is no doubt a foolish question, but I'd greatly appreciate it if a kind soul could set me straight. I've just checked out a CVS archive (I have Fedora Core 1 running on a laptop, if that matters). export CVSROOT=/usr/local/cvs mkdir $CVSROOT cd $CVSROOT cvs init cvs -d:pserver:[EMAIL PROTECTED] login cvs -z3 -d:pserver:[EMAIL PROTECTED] co modulename (I pasted in the instructions that were on the site, so I'm pretty sure I did it right.) Now I want to add a file to the local repository (by that I mean the sandbox). But I am on a laptop, not connected to the Internet. cd modulename cp /home/jim/newfilename . cvs add newfilename and the system objects unknown host ... (it names the host from which I checked out the material). Of course, I can see why it would give me such an objection on a commit or an update, but should I be getting it on an add or a status? It isn't the case that I have to be connected, is it? Sorry; I'm just not seeing something. Thanks, Jim Hefferon ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Sorry about this newby question
You have to be able to access the CVSROOT even for an add. The server will check to see if the file was previously deleted and if so retrieve it from the attic. Also, if the file were in a new directory the directory would be added to the repository. In general you should expect most cvs commands to cause the client to communicate with the server. I am not sure why you included the bit about cvs init. You are obviously checking out files from somewhere other than your local machine. You don't need to create a repository on your machine to use the client. You could have just done the checkout without doing that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Sent: Friday, June 03, 2005 8:01 PM To: info-cvs@gnu.org Subject: Sorry about this newby question Hello, I apologize in advance for what is no doubt a foolish question, but I'd greatly appreciate it if a kind soul could set me straight. I've just checked out a CVS archive (I have Fedora Core 1 running on a laptop, if that matters). export CVSROOT=/usr/local/cvs mkdir $CVSROOT cd $CVSROOT cvs init cvs -d:pserver:[EMAIL PROTECTED] login cvs -z3 -d:pserver:[EMAIL PROTECTED] co modulename (I pasted in the instructions that were on the site, so I'm pretty sure I did it right.) Now I want to add a file to the local repository (by that I mean the sandbox). But I am on a laptop, not connected to the Internet. cd modulename cp /home/jim/newfilename . cvs add newfilename and the system objects unknown host ... (it names the host from which I checked out the material). Of course, I can see why it would give me such an objection on a commit or an update, but should I be getting it on an add or a status? It isn't the case that I have to be connected, is it? Sorry; I'm just not seeing something. Thanks, Jim Hefferon ___ 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: permissions question
chmod 2775 dirname [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello all: I am managing an unusual situation where we need to have several developers working on the same directory tree. Essentially I am using CVS as a logging mechanism, and to track revisions, but the software in question will only work in one place (don't ask). The problem is that each time I check something in, CVS changes the file's permissions to 755, so that my teammates can't change it. How do you control this behavior? I believe this behavior is also responsible for occasional up-to-date check failed messages. Since there is only one developer tree, there are no other versions of these files to change. These messages, I assume, are also caused by an owner or permission mismatch. Any advice? Many thanks, -tom tomfool at as220 dot org http://sgouros.com http://whatcheer.net ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
permissions question
Hello all: I am managing an unusual situation where we need to have several developers working on the same directory tree. Essentially I am using CVS as a logging mechanism, and to track revisions, but the software in question will only work in one place (don't ask). The problem is that each time I check something in, CVS changes the file's permissions to 755, so that my teammates can't change it. How do you control this behavior? I believe this behavior is also responsible for occasional up-to-date check failed messages. Since there is only one developer tree, there are no other versions of these files to change. These messages, I assume, are also caused by an owner or permission mismatch. Any advice? Many thanks, -tom tomfool at as220 dot org http://sgouros.com http://whatcheer.net ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: permissions question
[EMAIL PROTECTED] wrote: The problem is that each time I check something in, CVS changes the file's permissions to 755, so that my teammates can't change it. How do you control this behavior? use directories setgid bit to ensure files checked in will stay group-writable. -- All warranty and guarantee clauses become void upon payment of the final invoice -- Financial General Shefields Corollaries n°2 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
CVS history question
Hello all, I am trying to set up some useful reporting for use with our CVS resources and have been asked to report on * modules that have checked out (not committed) by a specific hostname In other words, particularly for our anonymous, read only checkouts, we'd like to be able to say... that module X was checked out by the *.com domain 100 times in the past week (or whatever) and display some statistics to that effect. CVS log doesn't log checkouts, but CVS history does and I did find a nice web interface to allow novice users to generate their own histories. http://www.jamwt.com/CVSHistory/ However, I don't believe that CVS history logs IP# or hostname. While this info appears in my *system log*, I would not be able to tie the system log which does record IPs, etc... to the modules being checked out in CVS (at least from all my reading). does anyone have any suggestions? any help is appreciated. thx, ___ 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
Question on branches
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. Thanks Zeus.___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
CVS migration question
I would like to know the procedure/steps to follow to do a migration of a project under the CVS repository on a Windows XP box to a CVS repository under Linux. The CVS versions are same on both the boxes. I would like to retain all the version history and log information during the migration. Thanks ~Santhosh Santhosh Raghunath Tel: 781-348-8464 This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS migration question
You must be Dusty on CM Crossroads then? ;-) I've been thinking about this since reading it on CM Crossroads this morning. I don't think it would be too terribly complicated. On the server side, I think it's just a matter of packing up the entire repository and ftp'ing it to the new server (or just copying it if you have a samba share). My only concern is whether or not you'd have to worry about the ^M end-of-line problem between windows and Unix. I haven't had time to go play with that yet to see if it would be an issue. If it's not, you'd just have to make the appropriate changes to the configuration files once it's on the new server. On the user's client side, all users would have to do a cvs release on their local sandboxes, and then change their CVSROOT variables to reference the name of the new server. 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 Raghunath, Santhosh [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 05/12/2005 10:28 AM To:'info-cvs@gnu.org' info-cvs@gnu.org cc: Subject:CVS migration question I would like to know the procedure/steps to follow to do a migration of a project under the CVS repository on a Windows XP box to a CVS repository under Linux. The CVS versions are same on both the boxes. I would like to retain all the version history and log information during the migration. Thanks ~Santhosh Santhosh Raghunath Tel: 781-348-8464 This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying or distribution or use of the contents of this information is prohibited. If you have received this electronic transmission in error, please notify the sender immediately by replying to the address listed in the From: field. ___ 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: CVS migration question
[EMAIL PROTECTED] wrote: I've been thinking about this since reading it on CM Crossroads this morning. I don't think it would be too terribly complicated. On the server side, I think it's just a matter of packing up the entire repository and ftp'ing it to the new server (or just copying it if you have a samba share). That's the bulk of it. You would have to update (or more likely rewrite) any scripts, such as commitinfo, loginfo, etc. My only concern is whether or not you'd have to worry about the ^M end-of-line problem between windows and Unix. Nope. RCS file format always uses a plain ASCII LF character as the line terminator, regardless of the platform the RCS file lives on. It's the client that translates LF into the appropriate line terminator for the client platform. -- Jim ___ 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
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
Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep
I'm trying to set the environment variable CVSROOT=/usr/local/cvs-rep. I use the export command like this in the terminal: export CVSROOT=/usr/local/cvs-rep. When I exit the terminal, (which runs the default bash) the variable cvsroot goes away. I have looked in a bunch of places which say that the export command makes for permanent environment variables. I am running redhat 8.0. Can someone tell me how I get the var to stay? ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep
It's working just as designed. :-) Variables that stay around permanently only stay that way as long as you are logged in. I suggest adding it to your .bashrc file in your home directory. UNIX/Linux process that file every time a new terminal session is opened and will set it automatically at that time as a part of your profile setup. 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 [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04/21/2005 04:14 PM To:info-cvs@gnu.org cc: Subject:Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep I'm trying to set the environment variable CVSROOT=/usr/local/cvs-rep. I use the export command like this in the terminal: export CVSROOT=/usr/local/cvs-rep. When I exit the terminal, (which runs the default bash) the variable cvsroot goes away. I have looked in a bunch of places which say that the export command makes for permanent environment variables. I am running redhat 8.0. Can someone tell me how I get the var to stay? ___ 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: Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep
It's working just as designed. :-) Variables that stay around permanently only stay that way as long as you are logged in. I suggest adding it to your .bashrc file in your home directory. UNIX/Linux process that file every time a new terminal session is opened and will set it automatically at that time as a part of your profile setup. You may also want to consider adding the variable to: /etc/profile or /etc/bashrc to make $CVSROOT available to all users - if you have permission to edit those files. -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep
Ahh, thank you very much :) Now I know why it doesn't work! Thank you! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Silly question about CVS and permissions
Folks,
I'm COMPLETELY new to CVS, and am assisting the CVS
administrator configure the tool on a Linux server. I've got a cursory
understanding of the CVSROOT directory structure; my question is one of
permissions. I realize that this has probably been addressed in the past, but
reading through the archives, I've not found, or not understood the
resolution here.
My understanding is that I ought to set up an account for a ${CVSADMIN}
user, and create a ${CVS} group. In the ${CVSROOT}/CVSROOT directory, all
files should be owned by ${CVSADMIN}, and have very restricted permissions. My
question comes from the remainder of the tree. If I've got users User1,
User2, and User3, all using this repository, I want to make sure that none of
these users either accidentally or maliciously destroy or damage the entire CVS
tree. My understanding is that User1, User2, and User3 must all belong to the
${CVS} group in order for things to work properly. If the permission scheme
for the ${CVSROOT} directories looks as follows:
config-files (${CVSADMIN}:750)
(640)
/
file2 (User2:700)
/ /
CVSROOT (${CVSADMIN}:700) bin (${CVSADMIN}:770)
- file1 (User1:700)
/ /
/ /
${CVSROOT} (${CVSADMIN}:755) - ProjectDir1 (${CVSADMIN}:
770)
\
\
ProjectDir2 (${CVSADMIN}: 770)
there doesn't seem to be anything that prevents User1
from going into the ProjectDir1/bin directory and removing file2 (which is
owned by User2). The directory permissions don't allow User1 to MOFIDY
file2, but they do allow him to REMOVE file2, if he uses the force option on
the rm command. Alternatively, if I set file permissions for the directories
to be 700 rather than 770, then neither User1 nor User2 can work with CVS.
I've kludged a solution, which is to set the setuid
flag on the cvs executable, but I've seen a number of posts that indicate
that isn't a wise move, and I've now got some problems with the
update and status command from remote machines, saying that the directories don't
exist (interestingly enough, I can check in and update files, but I can't
do the same with directories). The exact error is:
cvs server: ignoring ${PROJECTDIR1}
(CVS/Repository missing)
where ${PROJECTDIR1} is the name of the directory that I'm
trying to update.
Given the background presented here:
Is it the design of CVS that
any user that needs to check in/out files must have read/write permission
on all of the directories into which he/she can check in files (meaning
that he/she has remove permission at the O/S level within these
directories)? If so, I'll stop trying to solve this problem.
Are my (CVS/Repository missing)
messages related to the setuid that I've done on the cvs executable?
If the previous is true, is
that because setuid is truly not supported for the cvs executable, or is
it something that I've misconfigured?
If there is a way to prevent
destruction of files, and it is not through setuid, what is the method by
which I would accomplish this?
Any or all recommendations/solutions would be appreciated.
Thanks.
Dan Michaelis
Database Administrator/Developer
eOriginal
351
West Camden Street
Suite 800
Baltimore, MD 21201
410.625.5187 (phone)
410.659.9799 (fax)
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Silly question about CVS and permissions
Michaelis, Daniel writes: This is a multi-part message in MIME format.Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! SNIP there doesn't seem to be anything that prevents User1 from going into the ProjectDir1/bin directory and removing file2 (which is owned by User2). SNIP 1) the users should not be working directly in the repository except in very rare cases and should be approved for doing the work there, this should be a stated company policy. 2) if you are using ssh, ssh can be configured to limit the commands allowed to be ran by the user(except if the user figures out a hole in the programs they are allowed to run, see the next item). 3) if the user is violating company policy, whether or not that involves breaking another program, discipline appropriately. SNIP I've kludged a solution, which is to set the setuid flag on the cvs executable, but I've seen a number of posts that indicate that isn't a wise move, and SNIP This sounds like a pserver problem, and if you are worried about security, you don't use pserver. SNIP 1.Is it the design of CVS that any user that needs to check in/out files must have read/write permission on all of the directories into which he/she can check in files (meaning that he/she has remove permission at the O/S level within these directories)? If so, I'll stop trying to solve this problem. Yes. 2.Are my (CVS/Repository missing) messages related to the setuid that I've done on the cvs executable? Unknown, which method are you using to login? what does `echo $CVSROOT` return or what are you passing after `cvs -d`? 3.If the previous is true, is that because setuid is truly not supported for the cvs executable, or is it something that I've misconfigured? 4.If there is a way to prevent destruction of files, and it is not through setuid, what is the method by which I would accomplish this? The users should only be accessing the repository through cvs. The company should make a written policy that the users will only access the repository through cvs. The users should be trained that they should only access the repository through cvs, and that it is company policy. The company should only (I hope this is common sense) higher and retain employees who can understand and follow company policies regarding destruction of company property(code base in this case). technology can help a little here, keep the cvs repository on a machine which has been setup for ssh access and has ssh access limited to running cvs, for all but administrative people. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Silly question about CVS and permissions
Todd, Thanks for the answers. Regarding your comments, my intent is less to provide a secure environment (we don't expose cvs outside the internal network), and I'm not terribly worried about malicious destruction of data; I'm much more concerned with the occasional fat-fingered mistake that folks make, or the mistaken impression that they're on server A when, in fact they're on server B. As such, it's probably not worth the administrative hassle to restrict ssh (but you're right; that's probably the best solution for a secure environment). I'm not using pserver; I had mistakenly assumed that someone had mucked with permissions on the cvs executable, because I mistakenly assumed that it would take advantage of the setuid capability in a Unix environment, and manage reading/writing on its own. The errors that I was getting were undoubtedly due to the setuid that I used; when I revoked that, the problems disappeared. I'm not sure why those messages would be generated, but a number of posts indicate that there are problems with setuid on the cvs executable. Again, thanks for the input. Dan Michaelis Database Administrator/Developer eOriginal 351 West Camden Street Suite 800 Baltimore, MD 21201 410.625.5187 (phone) 410.659.9799 (fax) -Original Message- From: Todd Denniston [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 3:15 PM To: Michaelis, Daniel Cc: 'info-cvs@gnu.org' Subject: Re: Silly question about CVS and permissions Michaelis, Daniel writes: This is a multi-part message in MIME format.Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! SNIP there doesn't seem to be anything that prevents User1 from going into the ProjectDir1/bin directory and removing file2 (which is owned by User2). SNIP 1) the users should not be working directly in the repository except in very rare cases and should be approved for doing the work there, this should be a stated company policy. 2) if you are using ssh, ssh can be configured to limit the commands allowed to be ran by the user(except if the user figures out a hole in the programs they are allowed to run, see the next item). 3) if the user is violating company policy, whether or not that involves breaking another program, discipline appropriately. SNIP I've kludged a solution, which is to set the setuid flag on the cvs executable, but I've seen a number of posts that indicate that isn't a wise move, and SNIP This sounds like a pserver problem, and if you are worried about security, you don't use pserver. SNIP 1.Is it the design of CVS that any user that needs to check in/out files must have read/write permission on all of the directories into which he/she can check in files (meaning that he/she has remove permission at the O/S level within these directories)? If so, I'll stop trying to solve this problem. Yes. 2.Are my (CVS/Repository missing) messages related to the setuid that I've done on the cvs executable? Unknown, which method are you using to login? what does `echo $CVSROOT` return or what are you passing after `cvs -d`? 3.If the previous is true, is that because setuid is truly not supported for the cvs executable, or is it something that I've misconfigured? 4.If there is a way to prevent destruction of files, and it is not through setuid, what is the method by which I would accomplish this? The users should only be accessing the repository through cvs. The company should make a written policy that the users will only access the repository through cvs. The users should be trained that they should only access the repository through cvs, and that it is company policy. The company should only (I hope this is common sense) higher and retain employees who can understand and follow company policies regarding destruction of company property(code base in this case). technology can help a little here, keep the cvs repository on a machine which has been setup for ssh access and has ssh access limited to running cvs, for all but administrative people. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Silly question about CVS and permissions
Michaelis, Daniel wrote: Todd, Thanks for the answers. Regarding your comments, my intent is less to provide a secure environment (we don't expose cvs outside the internal network), and I'm not terribly worried about malicious destruction of data; I'm much more concerned with the occasional fat-fingered mistake that folks make, The big trick here is to reduce the reason for them to be _where_ they can make a fat-finger. As I (in an overbearing manner) suggested, only put things in the repository that the users need to get to through cvs, and if you are CMing other things, they should be in other directories that are controlled by a different CM agent (which might be A single human||user), not all users need write access to _all_ the directories with the artifacts contained in them. or the mistaken impression that they're on server A when, in fact they're on server B. As such, it's probably not worth the administrative hassle to restrict ssh (but you're right; that's probably the best solution for a secure environment). To solve the server A vs B problem, on our lan we use rsh and some ssh. The big thing though is to get the users to _ consistently _ use the _ remote _ access method, even when they are on the server local to the hard drive. In short, all users should ALWAYS use a remote access method to the same 'remote' computer even when they are on the 'remote' computer. I have accomplished this by having a script for each project, that when the person changes to a new project they start sourceing the appropriate script to setup things like $CVSROOT, path to libs, compilers and programing tools (as needed), this way we have configuration management over the pertinent parts of the environment the program is being created in. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Newbie cvs question - large project
[EMAIL PROTECTED] wrote: Thanks for the replies. Regarding the 'millions of source files' remark - sorry, but what I meant was my project has thousands (2000+) of source files, with a combined size (including bitmap resources etc) of hundreds of megabytes. Ah, that sounds much more sane and manageable. That said, could you give a tip on what's the best way for the programmers to modify the project? Same as I said the other day - try to break it down into smaller modules that can be compiled independently. Also keep in mind that you don't have to do a full checkout every time someone checks in a file - you only have to update the file(s) that changed. -- 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: Newbie cvs question - large project
Hi Jim, Alan Thanks for the replies. Regarding the 'millions of source files' remark - sorry, but what I meant was my project has thousands (2000+) of source files, with a combined size (including bitmap resources etc) of hundreds of megabytes. That said, could you give a tip on what's the best way for the programmers to modify the project? Thanks! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
newbie question: issues with gserver method
Hi, I have configured CVS with gssapi and am using gserver connection method to access the server. I have an empty passwd file in CVSROOT and set systemauth=no in config file to ensure kerberos auth is used. I am able to connect to server with kerberos tickets and check out and checkin code. However I see two issues vis-a-vis pserver approach. 1. the server requires a local user id with same id as the kerberos authenticated user. 2. The file owner ships for committed files are changed to that of the local mapped user. In pserver, we had a system-user specification to map several users to one system user. Is the same possible, with gserver also? If not, how can I ensure multiple users can modify same file without issues? I am using a Fedora Core3 server. I am worried the permission changes might affect, as several users keep changing files on my repository continuously. Regards, -- Satya Prasad ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Newbie cvs question - large project
1.We are currently working on a large project now. As the project is currently under way, we are constantly making changes to the codes, with different people changing different part of the codes. In this situation, what is the best way to start implementing CVS? I was thinking of establishing a reference version, create a new module in CVS for this version, and have everybody checks out the version and start working from there. Is there a better way to do this? 2. As our project is very large, with millions of source files (literally), performing cvs release and checking out the whole project everytime are certainly not feasible. To overcome this, I was thinking of letting each programmer works on his/her own part of the code, so after the initial checking out of the whole project (as described in my first question), each programmer will only modify/commit his/her own codes. The drawback of this is of course nobody will have the complete newest version of the project. Is there a better way to do this? Thanks! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Newbie cvs question - large project
[EMAIL PROTECTED] wrote: 1.We are currently working on a large project now. As the project is currently under way, we are constantly making changes to the codes, with different people changing different part of the codes. In this situation, what is the best way to start implementing CVS? I was thinking of establishing a reference version, create a new module in CVS for this version, and have everybody checks out the version and start working from there. Is there a better way to do this? That's the general way of working. 2. As our project is very large, with millions of source files (literally), performing cvs release and checking out the whole project everytime are certainly not feasible. To overcome this, I was thinking of letting each programmer works on his/her own part of the code, so after the initial checking out of the whole project (as described in my first question), each programmer will only modify/commit his/her own codes. The drawback of this is of course nobody will have the complete newest version of the project. Is there a better way to do this? The mind boggles. *Millions* of source files? May I ask what kind of project this is? Your project sounds like it is completely out of control - and that's not something CVS, nor any other source control tool, is going to help you overcome. You're going to need some serious project management disciplines in place. Start by partitioning this into sub-projects which can be checked out and worked on independently of the other sub-projects. -- 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: Newbie cvs question - large project
Jim.Hyslop wrote: [EMAIL PROTECTED] wrote: --[clip]-- 2. As our project is very large, with millions of source files (literally), performing cvs release and checking out the whole project --[clip]-- The mind boggles. *Millions* of source files? May I ask what kind of project this is? Yes, please. Do tell. I am very curious. Alan ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
A question about tags and dates
Title: A question about tags and dates I think that this has been covered before, but I havn't been able to dig a definitive answer out of the docs or the FAQ so please bear with me. 1) Is it possible to tag a branch by date/time? (i.e will this put a tag SOMETAG on BRANCH_ONE as it was on 12 noon EST on March 10 2005 in the module MYMODULE) cvs -q rtag -r BRANCH_ONE -D 2005-03-10 12:00 EST SOMETAG MYMODULE 2) Is it possible to pull a branch by date/time or are the two sticky tags mutually exclusive? (i.e will this pull the branch as it was on 12 noon on March 10 2005) cvs -q checkout -r BRANCH_ONE -D 2005-03-10 12:00 EST MYMODULE Thank you for your patience. Harold Lynch ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Question
We have an offsite lab that currently pulls test suites from our cvs repository at our home office while running tests.. Problem is, the test suites in cvs are huge and will sometimes take hours to checkout over the dedicated pipe (vs a couple minutes when checked out at the home office). In order to speed things up, I'd like to set up a cvs read only mirror copy of the repository at the offsite that stays up to date automatically with the master repository. That way the offsite lab can checkout test suites without having to go through the pipe. My question is, does cvs support the notion of a read only mirror repo? Thanks in advance for any info. Mark Lancisi ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
quick question
Hi, Is there a way to detect if a tag is a tag or a branch, with taginfo? Thanks! ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: quick question
On Tue, Feb 22, 2005 at 04:52:35PM -0500, Jean-Pierre Sevigny wrote: Is there a way to detect if a tag is a tag or a branch, with taginfo? cvs status -v somefile? With kind regards, Baurzhan. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
How to Setup CVSROOT/modules Question
Title: Message Hi All, I was able to set up a CVS repository for my users and I'm very new in CVS. One user mentioned that he wants CVSROOT/modules capability to be working so that he can fetch a list of modules in the CVS repository. I have read some where this should be done by the user. Is this capability should be setup by an admin? If so, how do I do that? He access the CVS repository via TortoiseCVS client program. I'm really lost. Any inputs is appreciated. ThanksMary ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to Setup CVSROOT/modules Question
Title: Message In my case, I, as cvs admin, don't let users touch the ../CVSROOT directory. To set up the CVSROOT/modules for your user, do... cvs co CVSROOT/modules cd CVSROOT Add the following line in the CVSROOT/modules file modulename -a dir1 dir2 file1 file2 dir3/file3 cvs commit modulename, dir1, file1, etc. are of course the module name you want, and the files and dirs you want to include. Your user can then cvs co modulename and get what you specified in the modules file -chris -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wang, Mary YSent: Thursday, February 10, 2005 2:23 PMTo: info-cvs@gnu.orgSubject: How to Setup CVSROOT/modules Question Hi All, I was able to set up a CVS repository for my users and I'm very new in CVS. One user mentioned that he wants CVSROOT/modules capability to be working so that he can fetch a list of modules in the CVS repository. I have read some where this should be done by the user. Is this capability should be setup by an admin? If so, how do I do that? He access the CVS repository via TortoiseCVS client program. I'm really lost. Any inputs is appreciated. ThanksMary ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Question About CVS
Hi, How does the CVS work? I have read the documentation by Jim Blandy (https://www.cvshome.org/docs/blandy.html) but it doesn't say how the modified source code is updated into the server. Does it update to the server via HTTP or FTP connections? Our company is currently looking for a HTTP connection for updating as in some premises, there might be some firewall, not within our control, that blocks FTP connections. Regards, Jacky ___ 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: RV: Newbie question. How to manage replaced files
Spiro: Unified diff format will not solve the posters problem of safely committing arbitrary files. It will also create more work. As Pierre stated, Nestor should implement tighter guidelines for obtaining and submitting sources. This can be difficult if dealing with 3rdparty dev-co's (or internal management...) Anyhow, a possible solution is to ask that the entire _affected_ source tree with CVS info included be sent to you in an archive. (only include directories containing changed files.) Of course this means that you must ship a CVS tree to them to edit... but where else would they get the code? This is the only way to be able to safely check in changed code: - check out source modules that will be modified - tag these sources with a branch if you think they will break the head when merging - archive the sources - ship to modifier - recieve from modifier - add a safty tag (if you chose not to branch) - add changes on branch (or head if you chose not to branch) - build and test - merge changes into head if it was a success Really tho, this is a process problem. Not a cvs problem. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RV: Newbie question. How to manage replaced files
Hello, * On Sun, Jan 30, 2005 at 09:47:30PM + Pierre Asselin wrote: If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... Another possiblity is to tell all your external contributors to send in only patches, never the complete source file. I would suggest the unified diff format (-u). You would have to patch these diff files into your working copies. Furthermore, it is not you who must determine the version the external contributor used, but the contributor himself has to find this out. Regards, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RV: Newbie question. How to manage replaced files
Hi I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? Regards, Néstor Boscán ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: RV: Newbie question. How to manage replaced files
N?stor Bosc?n [EMAIL PROTECTED] wrote: I have been using CVS for some time and have encounter problems when somebody gives me a file that I have to replaced in my CVS sandbox. This always happens because sometimes I have people outside the organization and they send new versions of files that I have to replace in the sandbox and try to update and commit to the CVS Repository. What is the best way to manage this case? I would figure out what revision of the file the external user started with. Then I would create a branch at that revision, commit the modification to that branch and see if I can merge the branch back to the trunk. By extension, if people send you patch of the entire source tree, *based on a released version*, you can branch the entire tree off the corresponding release tag, apply the patch, commit, and decide whether you want to merge the branch. If you can't determine the revision or tag from which to branch, you probably need to tighten your controls a little... -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge question
Christopher Fouts wrote: This is done in userA's directory structure, which is based on branchA correct? So no userA's files now have userB's changes right? And now for the trunk to get userA's changes as well I do a ... cvs co proj cvs up -j branchA Correct? The first time, yes. If userA will continue to work on the branch, then userA needs to immediately apply a tag to the branch: cvs tag -r branchA branchA_last_merge_from_branch Then the next time userA merges, the commands will be: cvs co proj cvs up -j branchA_last_merge_from_branch -j branchA cvs tag -F -r branchA branchA_last_merge_from_branch A couple of By the ways: BTW1: The person doing the merge can use 'cvs update -A' instead of 'cvs co proj'. Either will work. BTW2: The person doing the merge does does not necessarily have to be userA, although userA would be best suited to figure out any conflicts that may arise. -- 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: Merge question
Thanks to ALL. I understand perfectly now, at least more so than yesterday! :) -chris -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 10:13 AM To: Fouts Christopher (IFNA MP DC); info-cvs@gnu.org Subject: RE: Merge question Christopher Fouts wrote: This is done in userA's directory structure, which is based on branchA correct? So no userA's files now have userB's changes right? And now for the trunk to get userA's changes as well I do a ... cvs co proj cvs up -j branchA Correct? The first time, yes. If userA will continue to work on the branch, then userA needs to immediately apply a tag to the branch: cvs tag -r branchA branchA_last_merge_from_branch Then the next time userA merges, the commands will be: cvs co proj cvs up -j branchA_last_merge_from_branch -j branchA cvs tag -F -r branchA branchA_last_merge_from_branch A couple of By the ways: BTW1: The person doing the merge can use 'cvs update -A' instead of 'cvs co proj'. Either will work. BTW2: The person doing the merge does does not necessarily have to be userA, although userA would be best suited to figure out any conflicts that may arise. -- 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
Merge question
When merging 2 branches, say HEAD to branchB, where branchB contains files NOT YET in HEAD, the branchA files get deleted. Any way to prevent this? cvs up options??? -j branchA -j HEAD proj IOW, what options do I need? -- Chris T Fouts ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge question
[EMAIL PROTECTED] writes: When merging 2 branches, say HEAD to branchB, where branchB contains files NOT YET in HEAD, the branchA files get deleted. Any way to prevent this? cvs up options??? -j branchA -j HEAD proj IOW, what options do I need? The ones you have, but you have to use the correct revisions with the -j options. The command above says to take all the changes between the tip of branchA and the tip of the trunk and apply them to the current files, which are presumably the tip of branchA. This will undo *all* of the changes on branchA, not just the new files. What you probably want to do is take the changes from the *base* of branchA to the tip of the trunk and apply them. If you didn't create a revision tag for the branch point when you created the branch, you'll have to do so now. -Larry Jones These things just seem to happen. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge question
Chris Fouts wrote: When merging 2 branches, say HEAD to branchB, where branchB contains files NOT YET in HEAD, the branchA files get deleted. Any way to prevent this? cvs up options??? -j branchA -j HEAD proj This tells CVS Take the difference between the tip of branchA and the tip of the trunk, and apply them to the current directory. That is most likely *not* what you want - this will make the current directory identical to the trunk (which is why your files keep disappearing ;-) IOW, what options do I need? You have all the options you need, you just need to get the right ones and in the right order. I'm not clear on exactly what you're trying to do - don't think of this as merging two branches, but rather as merging the changes from one branch into another. So, with that in mind, I will assume you meant merging the changes from the HEAD into the branch. The command is simply: cvs update -j HEAD Note that if you plan to do more than one merge, then you really need to apply a tag at the last merge point: cvs update -j HEAD cvs tag -r HEAD last-head-merge Then, the next time you update, you use that tag and HEAD: cvs update -j last-head-merge -j HEAD cvs tag -F -r HEAD last-head-merge Now, you may have noticed a small race condition: if someone checks something into HEAD between the 'update' and the 'tag' commands, then the version you merged will *not* be the version you just tagged. To avoid that problem, use a temporary tag; the complete sequence, each time you merge, is now: cvs tag -rHEAD tmp-tag-head-merge cvs up -j last-head-merge -j tmp-tag-head-merge cvs tag -F -r tmp-tag-head-merge last-head-merge cvs tag -d tmp-tag-head-merge Note: prior to the first merge, you'll have to apply the tag last-head-merge to the branch point. Merging from the branch to the trunk is handled similarly - just change all occurrences of 'head' or 'HEAD' to the branch 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: Merge question
I understand perfectly what the cvs command I outlined does. I just didn't know if there are options to modify the behavior. Let me explain. In my group of 4 developers, I've implemented a multi-branch integration strategy, where each developer has a branch off the trunk. Each developer then does his work on his branch. This strategy works for me, but may not work for everybody. For simplicity, take just 2 users, userA and userB with their respective branchA and branchB. So to integrate, userB submits his changes to the trunk correct? This may include new files/dirs that userA does NOT have yet. For userA to pick up these changes, he has to do a cvs up -j branchA -j HEAD proj on his current directory structure based on his branchA correct? There in-lies the problem... -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Jim.Hyslop Sent: Wednesday, January 26, 2005 12:18 PM To: info-cvs@gnu.org Subject: RE: Merge question Chris Fouts wrote: When merging 2 branches, say HEAD to branchB, where branchB contains files NOT YET in HEAD, the branchA files get deleted. Any way to prevent this? cvs up options??? -j branchA -j HEAD proj This tells CVS Take the difference between the tip of branchA and the tip of the trunk, and apply them to the current directory. That is most likely *not* what you want - this will make the current directory identical to the trunk (which is why your files keep disappearing ;-) IOW, what options do I need? You have all the options you need, you just need to get the right ones and in the right order. I'm not clear on exactly what you're trying to do - don't think of this as merging two branches, but rather as merging the changes from one branch into another. So, with that in mind, I will assume you meant merging the changes from the HEAD into the branch. The command is simply: cvs update -j HEAD Note that if you plan to do more than one merge, then you really need to apply a tag at the last merge point: cvs update -j HEAD cvs tag -r HEAD last-head-merge Then, the next time you update, you use that tag and HEAD: cvs update -j last-head-merge -j HEAD cvs tag -F -r HEAD last-head-merge Now, you may have noticed a small race condition: if someone checks something into HEAD between the 'update' and the 'tag' commands, then the version you merged will *not* be the version you just tagged. To avoid that problem, use a temporary tag; the complete sequence, each time you merge, is now: cvs tag -rHEAD tmp-tag-head-merge cvs up -j last-head-merge -j tmp-tag-head-merge cvs tag -F -r tmp-tag-head-merge last-head-merge cvs tag -d tmp-tag-head-merge Note: prior to the first merge, you'll have to apply the tag last-head-merge to the branch point. Merging from the branch to the trunk is handled similarly - just change all occurrences of 'head' or 'HEAD' to the branch 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 ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Merge question
Let me explain. In my group of 4 developers, I've implemented a multi-branch integration strategy, where each developer has a branch off the trunk. Each developer then does his work on his branch. This strategy works for me, but may not work for everybody. For simplicity, take just 2 users, userA and userB with their respective branchA and branchB. So to integrate, userB submits his changes to the trunk correct? This may include new files/dirs that userA does NOT have yet. For userA to pick up these changes, he has to do a cvs up -j branchA -j HEAD proj on his current directory structure based on his branchA correct? No. As I said in my previous post, you have a from branch and a to branch. When merging, the to branch must be active. Since you are merging to the trunk, you and your developers must 'cvs update -A' before merging. If the developer will continue to work on the branch after the merge, then use the strategy I mentioned in my other post: cvs tag -rHEAD tmp-tag-head-merge cvs up -j last-head-merge -j tmp-tag-head-merge cvs tag -F -r tmp-tag-head-merge last-head-merge cvs tag -d tmp-tag-head-merge except use 'userX' instead of 'head' or 'HEAD'. On the other hand, if the branch will no longer be used once the changes have been merged to the trunk, then it's much simpler: cvs update -A cvs up -j [branch-tag] -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Jim.Hyslop Sent: Wednesday, January 26, 2005 12:18 PM To: info-cvs@gnu.org Subject: RE: Merge question Chris Fouts wrote: When merging 2 branches, say HEAD to branchB, where branchB contains files NOT YET in HEAD, the branchA files get deleted. Any way to prevent this? cvs up options??? -j branchA -j HEAD proj This tells CVS Take the difference between the tip of branchA and the tip of the trunk, and apply them to the current directory. That is most likely *not* what you want - this will make the current directory identical to the trunk (which is why your files keep disappearing ;-) IOW, what options do I need? You have all the options you need, you just need to get the right ones and in the right order. I'm not clear on exactly what you're trying to do - don't think of this as merging two branches, but rather as merging the changes from one branch into another. So, with that in mind, I will assume you meant merging the changes from the HEAD into the branch. The command is simply: cvs update -j HEAD Note that if you plan to do more than one merge, then you really need to apply a tag at the last merge point: cvs update -j HEAD cvs tag -r HEAD last-head-merge Then, the next time you update, you use that tag and HEAD: cvs update -j last-head-merge -j HEAD cvs tag -F -r HEAD last-head-merge Now, you may have noticed a small race condition: if someone checks something into HEAD between the 'update' and the 'tag' commands, then the version you merged will *not* be the version you just tagged. To avoid that problem, use a temporary tag; the complete sequence, each time you merge, is now: cvs tag -rHEAD tmp-tag-head-merge cvs up -j last-head-merge -j tmp-tag-head-merge cvs tag -F -r tmp-tag-head-merge last-head-merge cvs tag -d tmp-tag-head-merge Note: prior to the first merge, you'll have to apply the tag last-head-merge to the branch point. Merging from the branch to the trunk is handled similarly - just change all occurrences of 'head' or 'HEAD' to the branch 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 ___ 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: Merge question
[EMAIL PROTECTED] writes: I understand perfectly what the cvs command I outlined does. It ain't the things you don't know that get you in trouble, it's the things you know that just ain't so. You do *not* understand what the CVS command you outlined does. For simplicity, take just 2 users, userA and userB with their respective branchA and branchB. So to integrate, userB submits his changes to the trunk correct? Correct. To be precise, userB merges his changes into the trunk. This may include new files/dirs that userA does NOT have yet. For userA to pick up these changes, he has to do a cvs up -j branchA -j HEAD proj on his current directory structure based on his branchA correct? NO! That *replaces* userA's directory with the current head of the trunk, *ERASING ALL OF USERA'S CHANGES*! UserA needs to merge the changes from where his branch split from the trunk (or, if he has previously merged changes from the trunk, the last revision he merged from) to the head of the trunk: cvs up -j branchA_root -j HEAD proj or cvs up -j branchA_last_merge -j HEAD proj (Note that both of those tags -- branchA_root and branchA_last_merge are actually on the *trunk*, not on branchA itself.) -Larry Jones It's a Doofus Ignoramus! Our hero slowly reaches for his stun blaster! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
fileInfoGenerated method usage question
Hi, folks. I am having trouble in capturing the output of a EditorsCommand. I have registered a CVSAdapter within my Client (client.getEventManager().addCVSListener(myListener); ), before executing the command. However, the output of the EditorsCommand is send through the messageSent(MessageEvent e) method, and not through the fileInfoGenerated(FileInfoEvent e), which in fact is never called. Of course, I would like to capture this output through the fileInfoGenerated, because it presents a more structured response. Am I doing something wrong? Shouldn't the method fileInfoGenerated be automatically called? Thanks in advance. BTW, I am using CVSNT. ___ 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
CVS tag question
All, I have a question concerning cvs update and tags. If another developer tags a set of files, but not the whole baseline, is there a way that I can get just the tagged files into my sandbox, but leave everything else in my sandbox alone? I know the correct behavior of cvs update -r tagname is to update just those tagged files and remove all other non-tagged files from the sandbox, but is there any way to not remove the non-tagged files? Thank you for your help, Melissa ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS tag question
Butler, Melissa wrote:
All,
I have a question concerning cvs update and tags. If another
developer tags a set of files, but not the whole baseline, is there a way
that I can get just the tagged files into my sandbox, but leave everything
else in my sandbox alone? I know the correct behavior of cvs update -r
tagname is to update just those tagged files and remove all other
non-tagged files from the sandbox, but is there any way to not remove the
non-tagged files?
Thank you for your help,
Melissa
1) get a list of the just tagged files, I _THINK_ the following will do it:
cvs -n update -r tagname 21|grep ^U|awk '{print $2}' updatethese.txt
2) update just those files, which will keep cvs from touching the rest of
the files.
for i in `cat updatethese.txt`;
do
cvs update -r tagname $i
done
3) note that all the files in updatethese.txt will now have sticky tag
tagname set, not sure how you should handle that (or if you need to). If
those files were the latest (HEAD) then you could drop the -r tagname,
assuming tagname is a normal tag, not a branch tag.
This is not intended to be direction to a gov contractor to do anything,
just a listing of information which _may_ answer the question which was
asked.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the WarfighterThe opinions expressed here are not sanctioned by and do not necessarily
represent those of my employer.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS tag question
cvs co -r tagname -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Butler, Melissa Sent: Wednesday, January 19, 2005 10:48 AM To: info-cvs@gnu.org Subject: CVS tag question All, I have a question concerning cvs update and tags. If another developer tags a set of files, but not the whole baseline, is there a way that I can get just the tagged files into my sandbox, but leave everything else in my sandbox alone? I know the correct behavior of cvs update -r tagname is to update just those tagged files and remove all other non-tagged files from the sandbox, but is there any way to not remove the non-tagged files? Thank you for your help, Melissa ___ 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: CVS tag question
Butler, Melissa writes [in one very long line]: I have a question concerning cvs update and tags. If another developer tags a set of files, but not the whole baseline, is there a way that I can get just the tagged files into my sandbox, but leave everything else in my sandbox alone? I know the correct behavior of cvs update -r tagname is to update just those tagged files and remove all other non-tagged files from the sandbox, but is there any way to not remove the non-tagged files? Not easily. If the other files are just the current head of the trunk, you can use ``update -f -r tag''. Otherwise, you'll have to update just the specific files that have the tag rather than updating the entire directory. -Larry Jones Oh, what the heck. I'll do it. -- Calvin ___ 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
Question re: deleted tags
Ok, I deleted a CVS tag using cvs rtag -d tagname proj Now, when I do a check out with the tag, I get cvs co -r tagname proj cvs checkout: Updating proj/file1 cvs checkout: Updating proj/file2 cvs checkout: Updating proj/file3 .. I expected cvs [checkout aborted]: no such tag tagname What am I missing? -- Chris T Fouts ___ 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
newbie module question
Hi, I'm been using CVS informally in eclipse for about a year and I'm trying to figure it out a little more. Stupid question, but from reading the cvs manual all it really said about modules is that you can use them to group related files. Up to now I've just been committing my projects in separate folders off the cvs root. Should I make these separate projects separate modules? What advantages does a module offer? thanks. - dkrebs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 10:28 PM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! Kindly double-check the manual and the code. There's this: cvs -n commit ... and there's this: cvs commit -n ... There's a difference. The former means don't change disk. The latter means don't fire *info triggers. I believe that the latter should be removed, but that's just me. The latter *were* removed, over a year and a half ago, prior to the CVS 1.11.7 and 1.12.1 releases. References to the command option `-n' were removed from both the source and the manuals, for exactly the reasons you suggest they should have been. I did the work myself. There should be some emails discussing it in the archives, if you are interested. Cool!! :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: We've already discussed how to add such a capability in such a way that it involves zero overhead for those who don't want it: Register no triggers and defer their enforcement until commit time. But for shops that NEED them, they can register the trigger and turn off deferment. Contacting the server is not zero overhead. As Mark pointed out, it is much more compelling that users have complete control over conditions in their workspace and I would argue similarly for as much functionality working in disconnected mode as possible. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBngFBLD1OTBfyMaQRAtOCAJ9DnI4+tfBDSi33aTkYg4BskUPeWACdFiau BmoOqQ64atdSJwsVbvh2oI0= =5G34 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail. It does when they user is disconnected from the network or wants to generate a patch to mail to someone for review without committing the changes, at the least. The user should be able to make any changes they wish in their workspace. The server should only gate changes to the repository, except possibly when the user requests otherwise. There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example. Duh, not via CVS anyhow. They can do anything they want with other tools in their local workspace. I hope you are not proposing CVS run setuid root and prevent the user from altering their own files? Regardless, I am hardly proposing that CVS destroy a user's metadata. Why is having CVS aware of source files an enabler for producing patches? CVS will not generate patch data for files it is not aware of. For a new file to be listed in the diff, it needs to be added first. I don't consider triggers to be conveniences. If they are to enforce policy then they can't be defeated by the user. Your suggestion would be easy to defeat, regardless, and no policies should be enforced on the user's workspace without their request. This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons. Again, no! -n prevents any permanent changes from being made to the disk, anywhere! (I mention permanent because some temp files are created and used in the /tmp dir, but these are conveniences and safely go away when the command is finished so are irrelevant for our purposes.) `cvs -n add' would mean, CVS, tell me what `cvs add' would do, but don't change anything, meaning don't add the file! Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBngfsLD1OTBfyMaQRAmn4AJ9+3B1kKTQfbMOJdMxCdgMe0YTxeACgraCg bo2U7p1D5br3lnh09k3qEp4= =O5Zr -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] Derek Robert Price [EMAIL PROTECTED] writes: Mark D. Baushke wrote: Hi Greg, Is it reasonable to suggest that a addinfo trigger could be run as a part of the 'cvs commit' command should the client not happen to connect to the server for a 'cvs add' operation? It should probably run regardless since it would be much simpler than securely tracking whether the add on the client side had contacted the server. Good point. Yes! The idea would be that having simpler triggers for various kinds of policy makes the administration of a repository easier. In a similar manner a trigger for 'cvs rm' could be implemented to impose policy. Sure, but again, not by default. Sure. I think that it should be enabled by default, and the user can put the -n option in his .cvsrc file for the affected commands, both for add and remove. No! -n means don't change the disk! In other words, nothing is changed anywhere and the file would not be added locally. The reasons for this: - It maintains compatibility with existing commands. No, but to continue your logic, -C to request the validation would be consistent with the current behavior of `cvs commit' and `cvs edit' on feature. - The user is caught just once when the trigger fires. Recovery is to interrupt the client, edit .cvsrc, and re-run. In the converse, the user must ask for policy enforcement, and may never get around to it in violation of the project's policy. Policies should not be enforced until the change is to the repository where everyone else can see it. If your team really wants this behavior, you could always hack their clients, though, as I mentioned before, they can still get around any such enforcement using only a text editor. If it is really a lot of work to clean up after one of these mistakes, I expect most users won't forget to run add -C more than once or twice. If it is really, really, a lot of work, then you should be training them before hand to avoid the issue and probably installing a default .cvsrc for them which contains the `add -C' and `rm -C' options or providing them with hacked clients. Unfortunately, there appears to be no way to countermand a -n option, so the only way to turn it off is to edit the .cvsrc file. The -f option tells CVS to ignore the .cvsrc file for the duration of a command, but I have often thought it would be useful if every option had an opposite so that they could be countermanded individually on the command line. Of course, I haven't thought it would be so useful to actually be tempted to write the patch yet, as an easy solution, such as lower case being on and upper case being off would already break backwards API compatibility (for instance -r and -R already have very different meanings to CVS). Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBngoZLD1OTBfyMaQRAg2iAKDVf9KeXeESxMEDIioZoA4k6bgltwCgjk03 OGOdGv6eKFA/DzyZGVhu/QU= =UNGJ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Merge question?
My CVS client is on Widows XP Professional version 2002 with SP1. I need to merge a branch to the trunk, and since we have binary files in both places, I thought of performing the following steps to avoid merging the binary files: 1. From the trunk sand box, run the following command: cvs update -j Release_2_2_0 -j Release_2_2_0_Branch After the above command is done, Ill make a list of all the modified file by checking the .# files. 2. Ill update the trunk files by putting them back to their original state before the merge. 3. Based on the list I made earlier, Ill run the following command only on the files that needs to be merged: cvs update -kk -j Release_2_2_0 -j Release_2_2_0 filename My questions are: Q1. Is the above is the best method to use to handle the merge between branches when there are binary files that should NOT be merged? Q2. After I merge the text files using the -kk, do I need to reset the merged files to remove -kk option? Thanks, Sameh ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 6:38 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: It's simpler, but neither safer nor saner to wrapper script around the client. The reason is this: If you enforce policy but give the user an avenue to circumvent it, the user will do so. If you're serious about enforcing policy, then you must have a way to build it into your tools in a way that user cannot defeat. In CVS (and indeed most if not all existing version control systems), that means spawning trigger scripts from within the tool, because wrapper scripts are trivial to defeat. This argument is not applicable to workspace changes. The user can manually edit the CVS/Entries files to add or remove a file locally without ever contacting the server. Your proposed hook would never run in this case. This is a trivial hack and, in fact, there are already scripts out there that will do just this without the user even needing to learn the trivia required to edit the files by hand. If you truly believe that, If you enforce policy but give the user an avenue to circumvent it, the user will do so, then your proposed hooks would offer absolutely no improvement over the status quo for your reported purposes. Like I said in an earlier post, I also don't believe that the user should be given the ability to corrupt his metadata. But I won't argue about it, and acknowledge that with CVS it's a possibility. Also recall that there was agreement that the add hooks should fire before the commit triggers at commit time, so whatever they do would be done regardless. It's just a matter of timing. And if the user bypasses the trigger and gets bitten later, so be it. Remember the very strongest bit of advice for using CVS is to update and to commit early and often This is true, but it remains a common belief that nothing should be committed until it's ready for unlimited use by the rest of the project. As long as that paradigm holds, work will continue to be done for long periods of time between commits. Your users should be committing changes to branches until they are ready for shared branches. There is no excuse for what you describe except ignorance or laziness. I agree. But I play with what I'm dealt. BTW, using the submit/assemble mechanism discussed here in the past, it is possible to commit to shared branches under certain conditions and still have an efficient (and very livable) process. But that's a different topic. Claiming that the hooks are not needed in the context of current use is meaningless because the hooks do not currently exist. Such arguments can only be made if one can demonstrate that existing hooks are not used in a meaningful way. On the other hand, we have stated requirements where existing users find existing capability to be inadequate. This is compelling reason to add the requested feature. Sure, if the user needs to request the feature using `-C'. The would be no other excuse for a needless server contact after Greg's proposed patch otherwise (which states in detail the direction I've thought development needed to go for awhile), except possibly if the add would continue if the server contact failed, but the more I think about it, the more I think even this is inappropriate without the user specifying the option. Looks like this part of our argument boils down to whether or not the trigger should fire by default. You say no, I say yes. However, we can have our cake and eat it too, if add-time hooks are implemented in the following way (which I summarize from prior posts): - Register add-time hooks in a new *info file. - Invoke the registered script at both of the following times: - User invokes cvs add - User invokes cvs commit, before commitinfo triggers fire. - Give the user the ability to defeat the add-time trigger in one of two ways: - Turn it on by default but use -n at add time to skip it, as I recommend. - Turn it off by default and add a new option to invoke it. As I mentioned before, the user should have complete control over their workspace. This includes being able to add and remove files in their workspace even when they do not have write privileges on the server, much less without letting the server abort the addition via an external script. Any other solution would mean that users could not generate complete diffs based on data they were not ready to commit. (This problem of complete diffs is actually the status quo since add still contacts the server. CVS will not calculate a diff for files is not tracking, at least locally, so to get new files into a diff, they need to be added locally. Unfortunately, this currently means contacting the server and having write privileges in the repository in question, which means that this cannot be done against an anonymous repository, or indeed any where the user has no write privs, without hacking the CVS/Entries file to add files by hand.) Okay, I'm
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 19, 2004, at 6:49 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: There is a certain logic to having triggers gate changes to the repository. There's also a certain logic to having a tool prevent conditions that will later cause it to fail. Uncommitable changes are such a condition, and it simply makes no sense to allow adds to succeed when we know that committing those adds will fail. It does when they user is disconnected from the network or wants to generate a patch to mail to someone for review without committing the changes, at the least. The user should be able to make any changes they wish in their workspace. The server should only gate changes to the repository, except possibly when the user requests otherwise. Fair enough. There's another point I'll make but won't argue over: There's a limit to the amount of control a user should have, even over his own workspace. The user shouldn't be able to corrupt his metadata to the extent that it causes failures, for example. Duh, not via CVS anyhow. They can do anything they want with other tools in their local workspace. I hope you are not proposing CVS run setuid root and prevent the user from altering their own files? Regardless, I am hardly proposing that CVS destroy a user's metadata. Actually, all I'm suggesting is that we should maybe consider ways of moving CVS metadata out of the user's workspace. But that's a different argument, and one that I'm not willing to pursue right now. Why is having CVS aware of source files an enabler for producing patches? CVS will not generate patch data for files it is not aware of. For a new file to be listed in the diff, it needs to be added first. I don't consider triggers to be conveniences. If they are to enforce policy then they can't be defeated by the user. Your suggestion would be easy to defeat, regardless, and no policies should be enforced on the user's workspace without their request. This assumes that policies as set by project management are voluntary. People who bypass them have a way of affecting the project in ways that management won't tolerate for long. This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! Kindly double-check the manual and the code. There's this: cvs -n commit ... and there's this: cvs commit -n ... There's a difference. The former means don't change disk. The latter means don't fire *info triggers. I believe that the latter should be removed, but that's just me. However, if applied to the add command, it is more agreeable than the -C option as described above for human engineering reasons. Again, no! -n prevents any permanent changes from being made to the disk, anywhere! (I mention permanent because some temp files are created and used in the /tmp dir, but these are conveniences and safely go away when the command is finished so are irrelevant for our purposes.) `cvs -n add' would mean, CVS, tell me what `cvs add' would do, but don't change anything, meaning don't add the file! What I've been trying to say is that the following is agreeable: cvs add -n ... If this form of -n remains compatible with the other trigger no-op options (like cvs commit -n ...), then it could be put in the user's .cvsrc file to defer add-time triggers until commit time. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: This is why I hate the -n option of the checkout/commit/tag/update commands and advocate its removal from CVS. What in the world are you talking about??? -n prevents changes from being made anywhere! On the server or in the workspace! Why in the world would you care if the user can run a command which does nothing except tell the user what it would do if they actually ran it without - -n?!?!?!?!?!?!?!?!??!?!?!??!?!?!?!??!?! Kindly double-check the manual and the code. There's this: cvs -n commit ... and there's this: cvs commit -n ... There's a difference. The former means don't change disk. The latter means don't fire *info triggers. I believe that the latter should be removed, but that's just me. The latter *were* removed, over a year and a half ago, prior to the CVS 1.11.7 and 1.12.1 releases. References to the command option `-n' were removed from both the source and the manuals, for exactly the reasons you suggest they should have been. I did the work myself. There should be some emails discussing it in the archives, if you are interested. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnuQlLD1OTBfyMaQRAgvZAJ9o05rbhpQbmNEVAcGiODOPGhnklwCfdo5B oAbEIW2J9gNu27JY35AwAn8= =hxSM -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] Paul Sander wrote: It's true that add and commit hooks can enforce the same kinds of policies as post-conditions of the commit. However, add hooks can enforce things like naming conventions. I'm working in a shop right now that prefers to have additions to the source tree (particularly new directories) be made by the architects of the project rather than the rank and file, and such a policy is best enforced at add time. The reason why I say these are best done at add time is because if the add succeeds then the user is likely to do a lot more work under the assumption that the subsequent commit will succeed (or at least not fail due to conditions created by the add). If the commit fails due to an improper add, then the user must re-do (or un-do) a bunch of work. All those hours of lost productivity could have been avoided by an add-time hook. This might be true, but it seems to me that most damage due to your lost productivity could be fixed with a rename or two and maybe a few `sed' runs, in a few minutes. At least in an environment where most of the files concerned were text files, as will usually be the case using CVS. It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. It might be interesting to see Greg's patch, but yours wouldn't be a big deal either, I think, as long as the add went forward without the hook execution when the server could not be contacted. The thing is, if there's a triggerable event, the trigger must be able to halt the event. Unplugging the network interface to enable adding a directory is simply not acceptable. On the other hand, requiring all add hooks to be replicated at commit time would eventually catch the error, and it could be argued that someone who attempts such tricks gets what they deserve, but it's just easier and better all around to just make the trigger act like a trigger. I still disagree, because some people like working from their laptop and wireless network connections are hardly ubiquitous yet. Work that a developer can do from their laptop off of the network can also provide additional productivity. It also means work a developer can do while the server is down. Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBnMIDLD1OTBfyMaQRAsXTAKCXZMFMEktr2ylkPgMFDkTe4cpIeQCgwkJt vjU0aUMTltYKjQQhvtnujio= =Dvk1 -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
On Nov 18, 2004, at 7:38 AM, [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- I still disagree, because some people like working from their laptop and wireless network connections are hardly ubiquitous yet. Work that a developer can do from their laptop off of the network can also provide additional productivity. It also means work a developer can do while the server is down. Well, I'm of the opinion that one shouldn't bother trying to use a client/server application while one is disconnected. :-) Systems like Monotone are better for what you're trying to do, where you can keep a local repository that syncs with others at appropriate times. Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can be placed in the user's .cvsrc for the add command and the add will not be allowed unless the server contact and verification is successful. If you're going to use triggers to enforce policy, then the user really shouldn't have the option to turn them off. Triggerable events should fire the triggers in a reliable way or else there's no point to them and they should in fact be removed on the basis that they only add cruft. Deferring them is okay, even as a client-side option, provided the user can't defeat them completely and the user is willing to accept the risk of lost work during the deferment period. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
[ On Wednesday, November 17, 2004 at 09:19:18 (-0800), Paul Sander wrote: ] Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes) It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. Your imagination is far too ripe with bizzare paranoia. There is no trigger for cvs rm and there MUST _NOT_ be. There is no trigger for cvs add and there MUST _NOT_ be. -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
