RE: Info-cvs Digest, Vol 36, Issue 29

[Harris, Sam]

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: address@hidden
[mailto:address@hidden On Behalf Of
address@hidden
Sent: None
To: address@hidden
Subject: Info-cvs Digest, Vol 36, Issue 29


Send Info-cvs mailing list submissions to
        address@hidden

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
        address@hidden

You can reach the person managing the list at
        address@hidden

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"
        <address@hidden>
Subject: RE: cvs remove and pre-commit check
To: <address@hidden>
Message-ID: <address@hidden>
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:address@hidden 
Sent: Thursday, 17 November 2005 8:10 AM
To: Lakshman Srilakshmanan
Cc: address@hidden
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" <address@hidden>
Subject: RE: CVS Core on AIX
To: "Derek Nerenberg" <address@hidden>,
        <address@hidden>
Message-ID:
        <address@hidden>
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:address@hidden 
        Sent: 17 November 2005 00:15
        To: Arthur Barrett; address@hidden
        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:address@hidden 
        Sent: Wednesday, November 16, 2005 3:35 PM
        To: Derek Nerenberg; address@hidden
        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:
address@hidden
[mailto:address@hidden On Behalf
Of Derek Nerenberg
                Sent: 16 November 2005 16:52
                To: address@hidden
                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 <address@hidden>
Subject: Re: Sub-directories not getting added to CVS/Entries
To: address@hidden
Message-ID: <address@hidden>
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 <address@hidden>
Subject: Re: Sub-directories not getting added to CVS/Entries
To: address@hidden
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

On 11/17/05, Spiro Trikaliotis <address@hidden> 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
> address@hidden 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
address@hidden http://lists.nongnu.org/mailman/listinfo/info-cvs


End of Info-cvs Digest, Vol 36, Issue 29
****************************************