Hello Folks, I have been told that our Agency has decided to use Subversion, and to start making plans (no hurry) to migrate to Subversion in FY06. Has anyone experienced this migration? Where should I begin and what do I need.
Sam -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: None To: info-cvs@nongnu.org Subject: Info-cvs Digest, Vol 36, Issue 29 Send Info-cvs mailing list submissions to info-cvs@nongnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/info-cvs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Info-cvs digest..." Today's Topics: 1. RE: cvs remove and pre-commit check (Lakshman Srilakshmanan) 2. RE: CVS Core on AIX (Arthur Barrett) 3. Re: Sub-directories not getting added to CVS/Entries (Spiro Trikaliotis) 4. Re: Sub-directories not getting added to CVS/Entries (Russ Sherk) ---------------------------------------------------------------------- Message: 1 Date: Thu, 17 Nov 2005 12:06:29 +1100 From: "Lakshman Srilakshmanan" <[EMAIL PROTECTED]> Subject: RE: cvs remove and pre-commit check To: <info-cvs@nongnu.org> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" HI Mark, Thank you very much for your help. I have fixed the problem. Just on another note what is your view on Subversion. I have been requested to investigate the possibility of migration to Subversion. I am particularly interested in the branching capability in Subversion. I am led to believe that it works similar to ClearCase. Thanks again. Lakshman -----Original Message----- From: Mark E. Hamilton [mailto:[EMAIL PROTECTED] Sent: Thursday, 17 November 2005 8:10 AM To: Lakshman Srilakshmanan Cc: info-cvs@nongnu.org Subject: Re: cvs remove and pre-commit check Lakshman Srilakshmanan wrote: > Hi All, I'm presuming that you are using 1.11.x. The following may apply to 1.12.x, but I don't know. First, read this: http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_18.html#SEC171 > I have a pre-commit check as follows. It checks to ensure that the cvs > tags Author, Revision and Header are present in the file. No, it doesn't > #!/bin/sh > > filename=$* > > dirName=$2 > > Author=`grep '\$Author' $filename` > if [ -z "$Author" ] ; then > echo "Author does not Exists" > exit 1 > fi <irrelevant commands removed from sample script> This isn't going to work. According the man page, the parameters passed to the command invoked by commitinfo are any parameters you put on the command line, followed by the repository directory and *all* the file names. Assuming you don't pass any other parameters to your script from your commitinfo file, your script's parameters will be dir f1 {f2 ...} So, what you should be doing is something like this: #!/bin/sh dirName=$1 shift for filename in $* do check file $filename done > It works fine for new files and changes. But when I commit after a "cvs > remove" I get the following error > > grep: sgs13.txt: No such file or directory > I understand, that since the file does not exist, grep can't find it. > But $* contains the following. > > /cvs/sgs/src/conf sgs13.txt Note : /cvs ==> is my "cvs > server root". > > > Therefore non of my greps should have worked as the file will be called > sgs13.txt,v under /cvs and > would not exist under the repository anyway (for new files). Your $filename variable value is incorrect. As you point out $* contains *the directory and the file name(s)*, so that's what is in $filename. So, your grep looks like this: grep '\$Author' /cvs/sgs/src/conf sgs13.txt This will fail to find $Author in the directory (obviously) but it may find it in sgs13.txt, and so assign it to the variable. For removed files, according to the manual when a file is being removed it will not exist in the current directory. So, you can't grep it. You should test it for existance before grep'ing it. Also, since there will be more than one file on the command line you must have a file loop as I said above. So combining the file loop and an existance test you would need: #!/bin/sh dirName=$1 shift for filename in $* do test ! -e $filename && continue egrep >/dev/null 2>&1 'blah' $filename || { echo "message" ; exit 1 ; } ... done > Q1. how does cvs know about my file when I am working from windows > client and the cvs server in on Linux. Q2. Why does it work for new > files when the directory is /cvs. New files > will not exist in the repository New and modified files are copied to a temp directory on the server. With a local repository they exist in your working directory. Removed files are not copied to the server, and they do not exist in your working directory. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_2.html#SEC26 > Q3. Any workaround ? You need to correct your script. -- ---------------- Mark E. Hamilton Orion International Technologies, Inc. Sandia National Laboratory, NM. 505-844-7666 ------------------------------ Message: 2 Date: Thu, 17 Nov 2005 14:15:07 +1100 From: "Arthur Barrett" <[EMAIL PROTECTED]> Subject: RE: CVS Core on AIX To: "Derek Nerenberg" <[EMAIL PROTECTED]>, <info-cvs@nongnu.org> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Derek, You seem to have forgotten to include a trace. Without the trace we can't see important information such as the CVSROOT that you are using, protocol etc. Does the same command (using exactly the same CVSROOT, including protocol and network address) work ok on the server? If you are using SSH ensure that the CVS_SERVER variable is set correctly on the client. 2.0.51d is getting pretty old now - but should never cause a crash on the server. Regards, Arthur -----Original Message----- From: Derek Nerenberg [mailto:[EMAIL PROTECTED] Sent: 17 November 2005 00:15 To: Arthur Barrett; info-cvs@nongnu.org Subject: RE: CVS Core on AIX I just downloaded the client which is the 2.0.51d version. When I try to login using command line options without JDeveloper even started, it cores out on the CVS server. I suspect there are problems with the versions. I'd like to download the correct client for a repository that's 1.11.5 version, but can't seem to figure out how / where to get the correct client. Any assistance would be greatly appreciated Thanks, Derek _____ From: Arthur Barrett [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 3:35 PM To: Derek Nerenberg; info-cvs@nongnu.org Subject: RE: CVS Core on AIX Derek, If you think the problem is related to/caused by the CVSNT client then you should address the question to the CVSNT newsgroup: http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt <http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt> or news://news.cvsnt.org/support.cvsnt <news://news.cvsnt.org/support.cvsnt> The first step in debugging what is going on is to get a trace: http://www.march-hare.com/cvspro/faq/faq2.asp#4L Try and rule out the JDeveloper GUI by using the command line for your tests instead, and give a specific example of something that causes a crash (ie: "everything" is not specific - does "cvs version" cause the crash? What about "cvs login"? etc For info on how to debug AIX core files you should probably ask either the GCC or AIX newsgroups... Regards, Arthur -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Nerenberg Sent: 16 November 2005 16:52 To: info-cvs@nongnu.org Subject: CVS Core on AIX Hello, I'm having a problem using the newest version of CVSNT client (via JDeveloper). Everything I do through the JDeveloper GUI will generate core files in /tmp. CVS 1.11.5 is running on AIX 5. I do not have admin privileges on the CVS repository, but am tasked with figuring this out. Can someone give me some instructions on using the debugger so I can interpret the cores for you? Kind Regards, Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gnu.org/pipermail/info-cvs/attachments/20051117/d03dd6ae/attach ment.html ------------------------------ Message: 3 Date: Thu, 17 Nov 2005 10:31:21 +0100 From: Spiro Trikaliotis <[EMAIL PROTECTED]> Subject: Re: Sub-directories not getting added to CVS/Entries To: info-cvs@nongnu.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii Hallo Mark, * On Wed, Nov 16, 2005 at 03:23:14PM -0700 Mark E. Hamilton wrote: > I'm having a strange problem. When I do a cvs checkout it seems to > work > fine. However, if I immediately follow it with an update some > sub-directories that it previously checked out show up with a '?'. The > sub-directory does not appear in the appropriate CVS/Entries file. > However, the sub-directory does contain a CVS sub-directory. > > So, cvs checked it out, but now it doesn't know about it. This happens > with multiple directories, but not all of them. Has anyone else seen > this before? > > My checkout command looks like this: > > cvs -f -d :ext:<server>:/cvsroot/sntools checkout sntools I have seen this behaviour when a Windows client is involved and the repository contains two directories which only differ in case. Anyway, this can occur anytime you want to check out the sandbox on an case-insensitive file system. For example: Assume you have a docs/ and Docs/ directory in the repository. If you check out, Windows maps both directories into the same local directory. I assume Docs/ is empty (at least, for the current checkout), but docs/ is not. If these are not empty, the result is even worse than the one I am describing here. Assume Docs/ is given by the server before docs/: In this case, the files in Docs/CVS/ are overwritten with the ones from docs/CVS/, which does not do much harm. Now, assume docs/ is given by the server before Docs/: In this case, the files in docs/CVS/ are overwritten with the ones from Docs/CVS/. Unfortunately, Docs/CVS/ has info about an empty directory. Now, CVS is very confused. I have helped myself in these cases by editing CVS/Entries.log and changing the case of Docs to docs. Now, an update works as expected. Notice: First, using -P on checkout does not help here, because CVS first checks out everything and prunes the directories afterwards. Secondly, do not use -d on check out, or your problem will come back. > Finally, following a checkout command immediately with another one > (which should basically be a no-op) generates a number conflict errors > for files in all the directores which have this problem. (Not > surprising, I suppose, given the other errors.) > > cvs checkout: Updating sntools/docs > cvs checkout: move away sntools/docs/FileLayout.txt; it is in the way > C sntools/docs/FileLayout.txt cvs checkout: move away > sntools/docs/glossary.html; it is in the way C > sntools/docs/glossary.html > Yes, this sounds exactly like the problem I am describing above. > The client and server I'm using are these: I have seens this problem with 1.11 and 1.12 versions of CVS. I remember seeing a post that special handling of Windows file systems was removed from the server in some 1.11.x version. Perhaps, this problem is related to this one? Ah, I found it: Changes between 1.12.2 and 1.12.3: ********************************** [...] GENERAL USER ISSUES * Support for case insensitive clients has been removed. This is not as drastic as it sounds, as all of the current tests still pass without modification when run from a case insensitive client to a case sensitive server. In the end this should provide a major stability improvement. [...] I have reported this problem before and even provided a script which shows this behaviour: http://lists.gnu.org/archive/html/info-cvs/2004-06/msg00343.html There, I only spoke of problems with release, but updates are problematic, too. Regards, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ ------------------------------ Message: 4 Date: Thu, 17 Nov 2005 08:36:18 -0500 From: Russ Sherk <[EMAIL PROTECTED]> Subject: Re: Sub-directories not getting added to CVS/Entries To: info-cvs@nongnu.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" On 11/17/05, Spiro Trikaliotis <[EMAIL PROTECTED]> wrote: > > Hallo Mark, > > * On Wed, Nov 16, 2005 at 03:23:14PM -0700 Mark E. Hamilton wrote: > > > I'm having a strange problem. When I do a cvs checkout it seems to > > work fine. However, if I immediately follow it with an update some > > sub-directories that it previously checked out show up with a '?'. > > The sub-directory does not appear in the appropriate CVS/Entries > > file. However, the sub-directory does contain a CVS sub-directory. > > > > So, cvs checked it out, but now it doesn't know about it. This > > happens with multiple directories, but not all of them. Has anyone > > else seen this before? > > > > My checkout command looks like this: > > > > cvs -f -d :ext:<server>:/cvsroot/sntools checkout sntools > > I have seen this behaviour when a Windows client is involved and the > repository contains two directories which only differ in case. Anyway, > this can occur anytime you want to check out the sandbox on an > case-insensitive file system. > > For example: > > Assume you have a docs/ and Docs/ directory in the repository. If you > check out, Windows maps both directories into the same local > directory. If this is the case, you may want to check that the one of the [Dd]ocs/ directories has been incorrectly added to the cvs repository. I had a similar error yesterday where in the repo there were 2 files test.txt an Test.txt. Test.txt was the real cvs file and test.txt should never have existed. To test this you need to 'cvs log' a file that is in the directory (cvs log sntools/docs/FileLayout.txt; cvs log sntools/Docs/FileLayout.txt). CVS should show a blank log message (no revisions, tags etc.) and the other should just spit out the log info. If this is the case, you can probably just BACKUP and remove the /cvsroot/sntools/[dD]ocs/ directory that has files with 'no head revision'. --Russ I assume Docs/ is empty (at least, for the current checkout), but docs/ > is not. If these are not empty, the result is even worse than the one > I am describing here. > > Assume Docs/ is given by the server before docs/: In this case, the > files in Docs/CVS/ are overwritten with the ones from docs/CVS/, which > does not do much harm. > > Now, assume docs/ is given by the server before Docs/: In this case, > the files in docs/CVS/ are overwritten with the ones from Docs/CVS/. > Unfortunately, Docs/CVS/ has info about an empty directory. Now, CVS > is very confused. > > I have helped myself in these cases by editing CVS/Entries.log and > changing the case of Docs to docs. Now, an update works as expected. > > Notice: First, using -P on checkout does not help here, because CVS > first checks out everything and prunes the directories afterwards. > Secondly, do not use -d on check out, or your problem will come back. > > > > Finally, following a checkout command immediately with another one > > (which should basically be a no-op) generates a number conflict > > errors for files in all the directores which have this problem. (Not > > surprising, I suppose, given the other errors.) > > > > cvs checkout: Updating sntools/docs > > cvs checkout: move away sntools/docs/FileLayout.txt; it is in the > > way C sntools/docs/FileLayout.txt cvs checkout: move away > > sntools/docs/glossary.html; it is in the way C > > sntools/docs/glossary.html > > > Yes, this sounds exactly like the problem I am describing above. > > > The client and server I'm using are these: > > I have seens this problem with 1.11 and 1.12 versions of CVS. > > > I remember seeing a post that special handling of Windows file systems > was removed from the server in some 1.11.x version. Perhaps, this > problem is related to this one? > > Ah, I found it: > > Changes between 1.12.2 and 1.12.3: > ********************************** > > [...] > > GENERAL USER ISSUES > > * Support for case insensitive clients has been removed. This is not > as drastic as it sounds, as all of the current tests still pass > without modification when run from a case insensitive client to a case > sensitive server. In the end this should provide a major stability > improvement. > > [...] > > > I have reported this problem before and even provided a script which > shows this behaviour: > > http://lists.gnu.org/archive/html/info-cvs/2004-06/msg00343.html > > There, I only spoke of problems with release, but updates are > problematic, too. > > Regards, > Spiro. > > -- > Spiro R. Trikaliotis http://cbm4win.sf.net/ > http://www.trikaliotis.net/ http://www.viceteam.org/ > > > _______________________________________________ > Info-cvs mailing list > Info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gnu.org/pipermail/info-cvs/attachments/20051117/0ec3f753/attach ment.html ------------------------------ _______________________________________________ Info-cvs mailing list Info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs End of Info-cvs Digest, Vol 36, Issue 29 **************************************** _______________________________________________ Info-cvs mailing list Info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs