Bryan,
Post by Bryan BattenIt worked!(?)
U bryan/FTPsites
exit
Great news!
Post by Bryan BattenBut, 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,
Post by Bryan Batten/usr/src/cvsroot
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