CVS Checkout Fails But Module Exists

2 views
Skip to first unread message

Bryan Batten

unread,
Aug 28, 2013, 9:37:14 AM8/28/13
to info...@gnu.org
I recently upgraded from Debian squeeze to wheezy and converted from 32
bit to 64 bit operation. In the process CVS went from 2:1.12.13+real-9
to 2:1.12.13+real-11. I now have a strange problem with the checkout
command.

To illustrate, there's a file in my home directory called FTPsites that
I added to my local repository six years ago. Things have been fine
since then till now.

Now, if I do "cvs co -p FTPsites" I get the message "cvs checkout:
cannot find module". However:
"cvs stat FTPsites" gives me the CVS status for that file.
"cvs log FTPsites" gives me the log entries for that file.
"cvs up -C FTPsites" creates .#FTPsites.1.1, then retrieves the file.
"cvs up FTPsites" will respond with "M FTPsites"

I've tried rolling back to the squeeze version and changing
architecture back to i386 from amd64, but the problem persists. I'm
pretty sure I have some weird environmental violation, but can't figure
out what it is. All levels of my local repository are writable, and
every command I use - except for checkout - appears to work.

I even went so far as to read the directions, but so far the last week
of googling and trying various possibilities hasn't helped, so ...

Hail Mary! and thanks in advance
--
Bryan
-
Basically, if I've stopped walking, you can pretty much tell I'm
chewing gum.

Arthur Barrett

unread,
Aug 28, 2013, 7:53:23 PM8/28/13
to Bryan...@gmail.com, info...@gnu.org
Bryan,

Trace? "cvs -ttt co -p FTPsites"

What's in your CVSROOT/modules file?

What is 'FTPsites' - a file/directory/link/module?

What result does 'cvs rls' give? And 'cvs rls FTPsites' ?

Also see the recent thread 'Re: cvs corrupts file while tagging' (a bug
report about cvs 1.12 x32 builds on x64 linux servers0. The bug has not
been confirmed but maybe you should either test it or switch back to the
x64 build.

Regards,


Arthur

Bryan Batten

unread,
Aug 29, 2013, 12:09:47 PM8/29/13
to Arthur Barrett, info...@gnu.org
Hey Arthur,

Thanks for the reply and interest in my problem. Here is the script
output of the three commands you requested:

--------------------------------snip-snip-----------------------------
Script started on Thu Aug 29 08:35:08 2013
]2;bryan@Pentium90 - /home/bryan[1] bryan: !503
bash: !503: event not found
[1] bryan: cvs -ttt co -p FTPsites
-> main: Session ID is 100521F6A4342F8EA9D
-> Name_Root ((null), (null))
-> parse_cvsroot (/usr/src/cvsroot)
-> walklist ( list=0x7fa6310c4c60, proc=0x7fa630e36d10, closure=(nil) )
-> main loop with CVSROOT=/usr/src/cvsroot
-> parse_config (/usr/src/cvsroot)
-> new_config ()
-> parse_info() examining line: `UseNewInfoFmtStrings=yes'
-> readBool (/usr/src/cvsroot/CVSROOT/config, UseNewInfoFmtStrings, yes)
-> Read 0 for UseNewInfoFmtStrings
-> my_module (FTPsites, Updating, NULL, NULL)
cvs checkout: cannot find module `FTPsites' - ignored
-> walklist ( list=0x7fa6310c4c60, proc=0x7fa630e36d10, closure=(nil) )
-> Lock_Cleanup()
-> remove_locks()
-> Simple_Lock_Cleanup()
[2] bryan: cvs rls
CVSROOT
bryan
etc
ralink
root
rtbis
rtsf
sap
x16854
[3] bryan: cvs rls FTPsites
cvs rls: cannot find module `FTPsites' - ignored
]2;bryan@Pentium90 - /home/bryan[4] bryan: exit
exit

Script done on Thu Aug 29 08:35:50 2013
------------------------------end-snip-snip---------------------------

To answer your other questions:

The file /usr/src/cvsroot/CVSROOT/modules consists entirely of comments.

The file 'FTPsites' is a plain ASCII text file. I chose it purely to
serve as an example. So far, the problem has occurred with *every* file
I've attempted to check out.

I looked at the thread in Google Groups gnu.cvs.help about file
corruption while tagging. Let me save what seems liable to exposure,
then try it. I'll follow through with an email on results.

I actually have switched CVS back to the 64 bit version, after having
tried squeeze:i386, squeeze:amd64, wheezy:i386:, and back to
wheezy:amd64. I've also tried the standard (wheezy:amd64) version using
a backup of /usr/src/cvsroot made prior to upgrading to wheezy and
converting to amd64.

Full disclosure: I ran into a *lot* of problems converting from i386 to
amd64. The system is basically functional (I'm using it to write this
email), but I think the cause of this problem is rooted in some subtle
environmental inconsistency more than CVS itself.

Again, thanks a lot.

On 08/28/13 16:52, Arthur Barrett wrote:
> Bryan,
>
> Trace? "cvs -ttt co -p FTPsites"
>
> What's in your CVSROOT/modules file?
>
> What is 'FTPsites' - a file/directory/link/module?
>
> What result does 'cvs rls' give? And 'cvs rls FTPsites' ?
>
> Also see the recent thread 'Re: cvs corrupts file while tagging' (a
> bug report about cvs 1.12 x32 builds on x64 linux servers0. The bug
> has not been confirmed but maybe you should either test it or switch
> back to the x64 build.
>
> Regards,
>
>
> Arthur
..
--
Bryan
-
Basically, if I've stopped walking, you can pretty much tell I'm
chewing gum.
G

Bryan Batten

unread,
Aug 29, 2013, 5:09:22 PM8/29/13
to Arthur Barrett, info...@gnu.org
Well, I cut and pasted the command from the OP in the "cvs corrupts
file while tagging" thread like so:

---
[29] bryan: cvs rtag -B -a -F -r 1.526 -b "my_tag" FTPsites
cvs rtag: cannot find module `FTPsites' - ignored
---
Same result as my "cvs co" problem. However, this is not a binary file.
Doesn't look like anything's corrupted, either

Thanks,

Arthur Barrett

unread,
Aug 29, 2013, 10:23:25 PM8/29/13
to Bryan...@gmail.com, info...@gnu.org
Bryan,

So let's try this.

1. Go to the directory where 'cvs update' works OK.

2. look at the three 'hidden' files in the CVS directory:
blah=`cat CVS/Root`
bling=`cat CVS/Tag`
blot=`cat CVS/Repository`

3. go to /tmp and use these pieces of information to test that 'checkout
works ok':

If all three files exist:

cd /tmp
cvs -d $blah co -r ${bling:1} ${blot}/FTPsites


If only CVS/Root and CVS/Repository exist:

cd /tmp
cvs -d $blah co ${blot}/FTPsites


Does that work?

Either way - send the info ($blah $bling and $blot) and we'll see if
that explains things some more...

-Arthur
> ...
> --
> Bryan
> -
> Basically, if I've stopped walking, you can pretty much tell I'm
> chewing gum.
> G
>

Bryan Batten

unread,
Aug 30, 2013, 5:11:28 PM8/30/13
to Arthur Barrett, info...@gnu.org
It worked!(?)

--------------------------------snip-snip-----------------------------
Script started on Fri Aug 30 14:00:43 2013
bryan@Pentium90 - /home/bryan[1] bryan: blah=`cat CVS/Root`
bryan@Pentium90 - /home/bryan[2] bryan: blot=`cat CVS/Repository`
bryan@Pentium90 - /home/bryan[3] bryan: echo $blah
/usr/src/cvsroot
bryan@Pentium90 - /home/bryan[4] bryan: echo $blot
bryan
bryan@Pentium90 - /home/bryan[5] bryan: cd /tmp
bryan@Pentium90 - /tmp[6] bryan: cvs -d $blah co ${blot}/FTPsites
U bryan/FTPsites
bryan@Pentium90 - /tmp[7] bryan: exit
exit

Script done on Fri Aug 30 14:02:12 2013
------------------------------end-snip-snip---------------------------

The only confusing part is that the checked out FTPsites is not in
/tmp. Instead it is in ~bryan/tmp, which is a symlink to /tmp/bryan.

But, hopefully, this tells us (and by "us", I mean "you") something.

Thanks,

Bryan Batten

unread,
Aug 31, 2013, 12:45:02 PM8/31/13
to Arthur Barrett, info...@gnu.org
Hi Arthur,

As a followup, I tried the following without cd'ing away from the
current directory:
----
[6] bryan: blah=`cat CVS/Root`
[7] bryan: blot=`cat CVS/Repository`
[8] bryan: echo $blah
/usr/src/cvsroot
[9] bryan: echo $blot
bryan
[10] bryan: cvs -d $blah co -p ${blot}/FTPsites
----
It worked like a charm, and the content of "FTPsites" scrolled down the
screen.

I considered the possibility of a permission problem. First, I compared
what I have now with that of a backup made in June. Other than showing
the change in my default umask from 0022 to 0077, they are the same.
Here are the current permissions:
----
drwxr-xr-x 8 root root 4096 Aug 31 2011 /home/
drwx--x--x 134 bryan projects 8192 Aug 31 08:37 /home/bryan/
drwx--s--x 2 bryan users 4096 Aug 28 08:54 /home/bryan/CVS/
-rw------- 1 bryan users 640 Aug 28 08:54 /home/bryan/CVS/Entries
-rw------- 1 bryan users 6 Jun 23 2007 /home/bryan/CVS/Repository
-rw------- 1 bryan users 17 Jun 23 2007 /home/bryan/CVS/Root
----
I tried changing the permissions on CVS/ to remove 'set ID on execute",
and change those of Entries, Repository, and Root from 600 to 644.
Checkout still fails with the same error message, so I backed out the
permissions changes.

Let me know what else I should try to provide information on my
problem, and thanks again.

On 08/29/13 19:22, Arthur Barrett wrote:

Arthur Barrett

unread,
Sep 1, 2013, 7:48:42 PM9/1/13
to Bryan...@gmail.com, info...@gnu.org
Bryan,


>
> It worked!(?)
>
> bryan@Pentium90 - /tmp[6] bryan: cvs -d $blah co ${blot}/FTPsites
> U bryan/FTPsites
> bryan@Pentium90 - /tmp[7] bryan: exit
> exit
>

Great news!

>
> But, hopefully, this tells us (and by "us", I mean "you") something.
>

I'll try.

Historically there has been a bit of confusion about checkout and update
- they are often used interchangably when I personally don't believe
that is good and probably not what was intended by the authors (but has
since been somewhat supported).

The following is my opinion, but one that I believe is strongly
supported by the history and documentation, but I'll happily acknowledge
that some (if not all) of what I'm about to say is open to argument.

There are times when you should use checkout.

There are times when you should use update.

Use checkout when: you have a new hard disk/empty directory.

Use update when: any time after the first 'checkout'.

If you have 'FTPsites' somewhere in your current directory then using my
above formula you should be using 'update' not checkout.


But why the odd results? That comes down to the ideological difference
between checkout and update.

When you perform a 'checkout' CVS stores some stuff in the 'sandbox' (or
'workspace' or 'directory' if you prefer) that is 'hidden' - this 'meta'
information describes the checkout, and includes:
- connection string to server (CVS/Root)
- path to the checked out directory/module in the repository
)CVS/Repository)
- branch/tag for each of the checked out files (CVS/Tag)


When you run 'cvs update' all of this information is 'loaded' into the
CVS Client and used as part of the 'query' for the server. If you go to
a new empty directory and do a checkout then all of this is not used.
[To confuse things a little more - you can also store some of this
'meta' information in the environment variables - but let's not
complicate things.]

You've proven that this works OK in your latest test. So why did it not
before? Well that's complex, and you may have found a bug in CVS 1.12,
but I personally think it's a low priority one because it's a case where
the 'correct' command to use is 'update' not 'checkout'. In many
versions of CVS if you do 'checkout' in a sandbox then it behaves like
'update' (Loads the connection string and path and branch from the
hidden files). I personally think the correct behaviour should be to
give a message 'use update not checkout'.

Skipping the rest of the lecture about theory and onto the practical,
your test shows us the 'missing' information:

> bryan@Pentium90 - /home/bryan[3] bryan: echo $blah
> /usr/src/cvsroot
> bryan@Pentium90 - /home/bryan[4] bryan: echo $blot
> bryan


So if you want to 'udpate':
cd to-the-sandbox
cvs update

If you want to 'checkout':
cvs co -d FTPsites bryan/FTPsites

Why didn't your original checkout work? Let's have a look:

cvs co -p FTPsites

This command tells CVS to checkout the module FTPsites. There is no
such module. The module is: bryan/FTPsites

Why did this change after the upgrade? It's either a bug before or
after. Either CVS was wrong to 'use' CVS/Repository to find the PATH to
the module before the upgrade, or CVS is wrong to ignore the
CVS/Repository PATH after the upgrade.

I don't care, and I'd argue it's an 'edge case' regardless. Best
practice tells me to use checkout with the full module name and update
with the relative module name. There is good reason for this best
practice: it forces me to know what the module name of my directory is
(bryan/FTPsites), which is important.

If you are going to continue to use this software, can I suggest you get
a good book about it and read it cover to cover? I can recommend
'Essential CVS' which is an old staple (for good reason), or 'All About
CVS' which I had a hand in writing.

* rant on *
Free software has garnered a bad reputation for me because some people
assume incorrectly that it won't cost them anything to use it. When
people pay $100,000 for software then spending $20,000 on training from
the vendor and a few weeks to learn the ins and the outs and calling the
vendors help desk is just par for the course. When some people pay
nothing for the software box they somehow assume they can also spend
nothing on training and very little time to learn it (or potentially
even worse, learn it from someone who has no connection with the
authors)... In my opinion commercial software is much more often
(though certainly not always) designed with the intention of helping the
'untrained' than 'free software' is, so if you'd spend $20,000 on
commercial software training, it's a good bet you need to spend $40,000
on free software training; if you'd spend 2 weeks getting to know
commercial software, it's a good bet you need to spend 4 weeks getting
to know free software.
* rant off *

Finally:

Your 'connection string' is: /usr/src/cvsroot which is 'really'
:local:/usr/src/cvsroot

CVS is a client/server version control system - it has a server, and it
has a client, and they communicate with a protocol. The 'connection
string' you are using indicates that you have disabled the client/server
protocol and are using it in 'local' mode. This mode has always been in
the software, and has gone through various stages of popularity. I
personally advise that unless you are an author of CVS, that it's not
for you - ie: it's a debug tool for the CVS developers, not something
the 'end user' (you) should use. May I suggest you 'switch' from using
'local' to using a client/server protocol like ssh (or if you must:
pserver)?

To make the change from 'local' to 'client/server' you will need to
either:

- 'delete' your sandboxes and 'checkout' with the new connection string,
or
- using a tool or script to manually alter all the 'CVS/Root' files.

Eg:

cd /tmp
rm -rf FTPsites
cvs -d :ext:/usr/src/cvsroot co -p FTPsites


You may find that you are now required to enter a password to run
operations like 'checkout' and 'update' - you can 'cache' the password
in several ways (ssh keys is probably the best) but I'll leave the
detailed explanations on all that to the book(s). The upshot of the
client/server protocol is you can now have several people all with
copies of your 'module' and keep them in sync and collaborate with a
team and your client and your server can be different computers that are
potentially quite some distance away from each other (eg: Sydney
Australia and London England).

Regards,


Arthur


Bryan Batten

unread,
Sep 1, 2013, 9:16:11 PM9/1/13
to Arthur Barrett, info...@gnu.org
Hey Arthur,

Thanks very much for delving into this issue for me. Going about
development without having full CVS functionality is not an option for
me, so I've been pretty much at a standstill for the last week or so. I
now have enough information that I can work around this particular item.

I think what I'll do is float it as a bug in Debian Wheezy and see what
happens. Having to do the extra typing to tack on a module component to
the checkout is a PITA.

On 09/01/13 16:48, Arthur Barrett wrote:
> Bryan,
..
> If you want to 'checkout':
> cvs co -d FTPsites bryan/FTPsites
>
> Why didn't your original checkout work? Let's have a look:
>
> cvs co -p FTPsites
>
> This command tells CVS to checkout the module FTPsites. There is no
> such module. The module is: bryan/FTPsites

Based on your observations, I tried this (while in my home directory
~/bryan):

cvs co -p bryan/FTPsites

and that worked too. Also, this works:

cvs up -p FTPsites

I now recall that previously, things like "co FTPsites" worked fine if
I was actually in the module directory, and would fail otherwise, which
is what I expected. If I recall correctly, if I was not in the module
directory, I needed to specify the relative or full path name to the
directory containing the file in question.

So it looks to me like the earlier CVS inferred the the module from
`pwd` - or possibly from $(basename $(pwd)).

>
> Why did this change after the upgrade? It's either a bug before or
> after. Either CVS was wrong to 'use' CVS/Repository to find the PATH to
> the module before the upgrade, or CVS is wrong to ignore the
> CVS/Repository PATH after the upgrade.

To me, the bug is an introduced incompatibility. Behavior has changed
in a way that makes this version of "co" incompatible with previous
versions.

..
> Arthur

Thanks again for your efforts,
Reply all
Reply to author
Forward
0 new messages