| 1 |
Using CVS (part 2) |
| 2 |
================== |
| 3 |
|
| 4 |
Contents |
| 5 |
-------- |
| 6 |
- Errata to "Using CVS (part 1)" |
| 7 |
- Setting up CVS on a Public PC (with WinCVS/SSH) |
| 8 |
- Setting up CVS off campus/SSB (with WinCVS/SSH) |
| 9 |
|
| 10 |
- How CVS handles binary files |
| 11 |
- Tagging the Repository |
| 12 |
- Branching in CVS |
| 13 |
- Keyword Expansion |
| 14 |
- Online CVS Resources |
| 15 |
|
| 16 |
- See "Using CVS (part 1)" for basic information on setting |
| 17 |
up and using CVS at UKC. |
| 18 |
|
| 19 |
tdb1, 29/10/00. |
| 20 |
|
| 21 |
Errata to "Using CVS (part 1)" |
| 22 |
------------------------------ |
| 23 |
Setting up CVS on a Public PC (with WinCVS/SSH) |
| 24 |
----------------------------------------------- |
| 25 |
Assuming you already have WinCVS working we just need to |
| 26 |
make a few modifications to get the same thing working with |
| 27 |
SSH. This will only work on a public PC, although with some |
| 28 |
careful copying of files you might be able to get it to work |
| 29 |
on a normal SSB machine. |
| 30 |
|
| 31 |
Firstly we need to get SSH working. As it is SSH does work, |
| 32 |
but it will keep prompting for a password, which is a pain |
| 33 |
when it's hidden in a cmd window somewhere. We'll start by |
| 34 |
tweaking the SSH setup, and then we'll setup a key pair to |
| 35 |
remove the need for a password. |
| 36 |
|
| 37 |
[adapted from instructions given by jc] |
| 38 |
|
| 39 |
First thing is to setup a few environment variables. This is |
| 40 |
done in the System part of Control Panel. Under the User |
| 41 |
Variables section add the following; |
| 42 |
|
| 43 |
HOME = |
| 44 |
z:\username |
| 45 |
CVS_RSH = |
| 46 |
ssh |
| 47 |
CVSROOT = |
| 48 |
:ext:user@raptor.ukc.ac.uk:/usr/local/proj/co600_10/cvs |
| 49 |
|
| 50 |
Next we need to go about setting up the key pair. This is |
| 51 |
done by two batch files called getkey.bat and copy-key.bat |
| 52 |
which are already on the public PC's. Unfortunately you need |
| 53 |
to modify getkey.bat to make it work with raptor, so copy it |
| 54 |
from the C: drive (c:\winnt\system32 I believe) to your |
| 55 |
desktop (or anywhere else). Edit it so that the third line |
| 56 |
reads; |
| 57 |
|
| 58 |
set HOST=raptor |
| 59 |
|
| 60 |
Then run it. You'll be prompted for your raptor password |
| 61 |
three times, and then the key is setup. Next you need to run |
| 62 |
copy-key.bat. Just go to "Start -> Run -> copy-key raptor" |
| 63 |
to make it do it's stuff. |
| 64 |
|
| 65 |
Now, we're pretty much all set. You should be able to type |
| 66 |
"ssh raptor" into a command window and log straight in |
| 67 |
without the need for a password. If not, something has gone |
| 68 |
wrong ! |
| 69 |
|
| 70 |
Finally, a quick alteration to WinCVS and we're done. In the |
| 71 |
preferences set the CVS Root to be; |
| 72 |
|
| 73 |
:ext:user@raptor.ukc.ac.uk:/usr/local/proj/co600_10/cvs |
| 74 |
|
| 75 |
Then set the Authentication type to "SSH server". Assuming |
| 76 |
you've already done the rest of the setup from the last |
| 77 |
document you should be able to do a checkout as normal, but |
| 78 |
this time without the need for a mapped drive - which is a |
| 79 |
much neater way of doing things. |
| 80 |
|
| 81 |
Setting up CVS off campus/SSB (with WinCVS/SSH) |
| 82 |
----------------------------------------------- |
| 83 |
To do this you'll need two packages. Firstly, and most |
| 84 |
obviously WinCVS. The latest version of WinCVS (1.1b16) can |
| 85 |
be downloaded from the "WinCvs 1.1 *BETA* / Client + Local / |
| 86 |
Binaries" on the following page; |
| 87 |
|
| 88 |
http://www.wincvs.org/download.html |
| 89 |
|
| 90 |
Secondly you'll require SSH. I'm not sure where this package |
| 91 |
orginated, but there is a current version on raptor at; |
| 92 |
|
| 93 |
/usr/local/proj/co600_10/sshwin32/ssh-1.2.14-win32bin.zip |
| 94 |
|
| 95 |
Armed with those two files you're ready to go. To get |
| 96 |
started we need to get ssh installed, and a key setup with |
| 97 |
raptor. |
| 98 |
|
| 99 |
Installing ssh is easy. Simply extract the contents of the |
| 100 |
zip file in to your windows\system32 directory (on |
| 101 |
winnt/win2k - windows\system on win9x). This will put the |
| 102 |
DLL's in place and the binary ssh files. |
| 103 |
|
| 104 |
Next, setting up a key. This requires a few straightforward |
| 105 |
steps. |
| 106 |
|
| 107 |
- setup a directory to be considered your "home folder" and |
| 108 |
then ensure that the environment variable HOME is pointed |
| 109 |
at this directory. Then make a directory called .ssh |
| 110 |
within this. |
| 111 |
|
| 112 |
- telnet into raptor and run this command; |
| 113 |
ssh-keygen -f ssh-newkey -q -P '' -C '<user> on NT'" |
| 114 |
|
| 115 |
make sure you change <user> for your userid, and that you |
| 116 |
notice the difference between the single quote ' and the |
| 117 |
double quotes ". |
| 118 |
|
| 119 |
- using ftp (or by any other means) copy the files named |
| 120 |
ssh-newkey and ssh-newkey.pub to the .ssh folder you made |
| 121 |
on your machine. Now rename them to identity and |
| 122 |
identity.pub respectively. |
| 123 |
|
| 124 |
- Finally we need to get the contents of the identity.pub |
| 125 |
file above into the file ~/.ssh/authorized_keys on |
| 126 |
raptor. The easiest way to do this is to type the |
| 127 |
following; |
| 128 |
cat ssh-newkey.pub >> .ssh/authorized_keys |
| 129 |
|
| 130 |
This assumes you didn't delete the ssh-newkey files, and |
| 131 |
that you are in your home folder. Finally, you can delete |
| 132 |
the ssh-newkey and ssh-newkey.pub files from raptor. |
| 133 |
|
| 134 |
Now, to test this setup you should try the following from a |
| 135 |
command prompt; |
| 136 |
|
| 137 |
ssh -l <userid> raptor.ukc.ac.uk |
| 138 |
|
| 139 |
If everything has completed successfully you should now be |
| 140 |
looking at a raptor prompt. If not... then work out why not! |
| 141 |
|
| 142 |
Right, now on to WinCVS. This is now a doddle. In the |
| 143 |
preferences set the CVSROOT to; |
| 144 |
|
| 145 |
:ext:<user>@raptor.ukc.ac.uk:/usr/local/proj/co600_10/cvs |
| 146 |
|
| 147 |
Set Authentication to SSH server, and set the RSA identity |
| 148 |
to your identity file (not the .pub one). Finally set the |
| 149 |
browser directory to a suitable location and try checking |
| 150 |
something out. If all has worked an SSH window should pop up |
| 151 |
at the bottom of the screen and the files should appear. |
| 152 |
|
| 153 |
As a final note, turning TCP/IP compression on may make it |
| 154 |
quicker over a modem. |
| 155 |
|
| 156 |
How CVS handles binary files |
| 157 |
---------------------------- |
| 158 |
Basically CVS can't do version management of binary files, |
| 159 |
and quite obviously this is because it's not possible to |
| 160 |
make version comparisons between two revisions in a logical |
| 161 |
way. But, CVS will let you store binary files and will let |
| 162 |
you add new versions. However, it will not store "changes" |
| 163 |
between them, or allow you to view diffs between them. |
| 164 |
|
| 165 |
IMPORTANT: You must make sure you tell CVS that a file is |
| 166 |
binary, otherwise it will not store it correctly |
| 167 |
and the file will be corrupted. |
| 168 |
|
| 169 |
In WinCVS it's really easy to add a binary file, simply |
| 170 |
select "Add selection binary" instead of the usual "Add |
| 171 |
selection". WinCVS will display a "binary" icon instead, and |
| 172 |
add "-kb" into the Option column. This -kb tells the CVS |
| 173 |
command that the file is binary. |
| 174 |
|
| 175 |
This leads nicely into how to do it from the command line. |
| 176 |
You simply type the following in place of the usual "cvs |
| 177 |
add" command. |
| 178 |
|
| 179 |
cvs add -kb <filename> |
| 180 |
|
| 181 |
Again, the -kb is present. Now, a quick explanation of what |
| 182 |
this "-kb" means. Basically it is telling CVS not to do |
| 183 |
keyword expansion (turning $Revision$ into $Revision: 1.3 $) |
| 184 |
and tell is not to attempt to convert between unix/windows |
| 185 |
text formats. |
| 186 |
|
| 187 |
Tagging the Repository |
| 188 |
---------------------- |
| 189 |
Tagging the repository is a way of "marking" all the files |
| 190 |
at a particular point in time. For example, when "release 1" |
| 191 |
is finished you might want to mark this in the history of |
| 192 |
all the files, so you can easily come back to it in the |
| 193 |
future. As every file the makes up "release 1" may be on a |
| 194 |
different individual revision, it would be tedious to do |
| 195 |
without the aid of tagging. |
| 196 |
|
| 197 |
This is the best example I've seen that clearly shows how a |
| 198 |
tag is implemented. Imagine the dotted line signfies the |
| 199 |
point at which you declared the files were "release 1". As |
| 200 |
you can see, work as continued on the files, but you could |
| 201 |
easily pull out each file at "release 1". |
| 202 |
|
| 203 |
File A File B File C File D File E |
| 204 |
------ ------ ------ ------ ------ |
| 205 |
1.1 1.1 1.1 1.1 1.1 |
| 206 |
---1.2-. 1.2 1.2 1.2 1.2 |
| 207 |
1.3 | 1.3 1.3 1.3 1.3 |
| 208 |
\ 1.4 .-1.4-. 1.4 1.4 |
| 209 |
\ 1.5 / 1.5 \ 1.5 1.5 |
| 210 |
\ 1.6 / 1.6 | 1.6 1.6 |
| 211 |
\ 1.7 / | 1.7 1.7 |
| 212 |
\ 1.8 / | 1.8 .-1.8-----> |
| 213 |
\ 1.9 / | 1.9 / 1.9 |
| 214 |
`1.10' | 1.10 / 1.10 |
| 215 |
1.11 | 1.11 | |
| 216 |
| 1.12 | |
| 217 |
| 1.13 | |
| 218 |
\ 1.14 | |
| 219 |
\ 1.15 / |
| 220 |
\ 1.16 / |
| 221 |
`-1.17-' |
| 222 |
|
| 223 |
In fact, if you imagine pulling this line straight, you'd |
| 224 |
get the following effect which even more clearly shows where |
| 225 |
"release 1" is. |
| 226 |
|
| 227 |
File A File B File C File D File E |
| 228 |
------ ------ ------ ------ ------ |
| 229 |
1.1 |
| 230 |
1.2 |
| 231 |
1.3 |
| 232 |
1.4 |
| 233 |
1.5 |
| 234 |
1.6 |
| 235 |
1.7 |
| 236 |
1.1 1.8 |
| 237 |
1.2 1.9 |
| 238 |
1.3 1.10 1.1 |
| 239 |
1.4 1.11 1.2 |
| 240 |
1.5 1.12 1.3 |
| 241 |
1.6 1.13 1.4 |
| 242 |
1.7 1.1 1.14 1.5 |
| 243 |
1.8 1.2 1.15 1.6 |
| 244 |
1.1 1.9 1.3 1.16 1.7 |
| 245 |
---1.2---------1.10--------1.4---------1.17--------1.8-----> |
| 246 |
1.3 1.11 1.5 1.17 1.9 |
| 247 |
1.6 1.17 1.10 |
| 248 |
|
| 249 |
Tagging is actually remarkably easy to do. All you do is |
| 250 |
issue a single command to tag the files at the current point |
| 251 |
in time. You should make sure all development stops whilst |
| 252 |
you do it, otherwise a bit of new code could sneak in. |
| 253 |
Here's how to do it; |
| 254 |
|
| 255 |
cvs tag public-release_1 |
| 256 |
|
| 257 |
This would mark the files with the tag "public-release_1". |
| 258 |
You can then continue with developement, knowing that all |
| 259 |
those files can easily be retrieved. It's again suprisingly |
| 260 |
easy to do. Instead of typing "cvs checkout source" you |
| 261 |
would type; |
| 262 |
|
| 263 |
cvs checkout -r public-release_1 source |
| 264 |
|
| 265 |
Which would checkout the source module at the point which |
| 266 |
you tagged. Alternatively the following would update (or |
| 267 |
downdate ?) your working copy to the tagged point; |
| 268 |
|
| 269 |
cvs update -r public-release_1 |
| 270 |
|
| 271 |
Finally, a quick mention of why this would be useful. |
| 272 |
Imagine the development team was split into two groups, one |
| 273 |
working on coding, another working on testing. When the |
| 274 |
coding group have finished "release 1" they can tag it and |
| 275 |
carry on developing for "release 2". At the same time, the |
| 276 |
testing team can checkout "release 1" and test it, reporting |
| 277 |
bugs back to the coding team for fixing in "release 2". It |
| 278 |
could also mean the a customer could still get hold of the |
| 279 |
first release whilst you're busy coding for the second. |
| 280 |
|
| 281 |
Branching in CVS |
| 282 |
---------------- |
| 283 |
So far I've only talked about a single CVS branch, the |
| 284 |
trunk. There is only ever one "current" revision of each |
| 285 |
file, and everyone is working on the same files. However, it |
| 286 |
is possible to branch this out into more than one copy of |
| 287 |
the same files. A good example of why this is useful is |
| 288 |
continuing the idea at the end of the last section. |
| 289 |
|
| 290 |
Imagine the coding team are now busy working on "release 2" |
| 291 |
and the testing team come up with a major flaw in |
| 292 |
the older "release 1". Customers have already got this |
| 293 |
version installed, so it needs fixing straight away. The |
| 294 |
trick is to make a branch at the point where "release 1" was |
| 295 |
tagged, and then fix the bugs on this branch. This branch |
| 296 |
need not carry on, it could just have the few bugs fixed, |
| 297 |
whilst the main branch (the trunk) has development of |
| 298 |
"release 2" carrying on. This diagram shows this; |
| 299 |
|
| 300 |
| |
| 301 |
| -- tag "release_1" |
| 302 |
|\ |
| 303 |
| \ |
| 304 |
| | |
| 305 |
| | |
| 306 |
| - -- tag "release_1-fixed" |
| 307 |
| |
| 308 |
| |
| 309 |
| -- tag "release_2" |
| 310 |
|
| 311 |
As you can see the customer could then get a copy of |
| 312 |
"release_1-fixed" and not worry about the unstable code in |
| 313 |
"release_2". |
| 314 |
|
| 315 |
Branches can get much more complicated than this, but it's |
| 316 |
beyond the scope of our requirements. Further info can be |
| 317 |
found on the web. |
| 318 |
|
| 319 |
Keyword Expansion |
| 320 |
----------------- |
| 321 |
CVS allows you to put certain keywords into a file which CVS |
| 322 |
will expand when you check files in and out of the |
| 323 |
repository. There are quite a few, and they're all pretty |
| 324 |
useful in places. Here's a quick summary; |
| 325 |
|
| 326 |
$Author$ |
| 327 |
The author of the latest change. |
| 328 |
eg. $Author: tdb1 $ |
| 329 |
|
| 330 |
$Date$ |
| 331 |
The date/time of the latest change. |
| 332 |
eg. $Date: 2000/10/30 13:10:04 $ |
| 333 |
|
| 334 |
$Header$ |
| 335 |
Various useful bits of information. |
| 336 |
eg. $Header: /usr/local/proj/co600_10/cvs/file.txt,v \ |
| 337 |
1.1 2000/10/30 13:00:00 tdb1 Exp tdb1 $ |
| 338 |
|
| 339 |
$Id$ |
| 340 |
Simliar to $Header$, but without that wieldy path. |
| 341 |
eg. |
| 342 |
$Id: cvs-2.txt,v 1.3 2000/10/30 13:10:04 tdb1 Exp $ |
| 343 |
|
| 344 |
$Log$ |
| 345 |
Puts the latest log message in. |
| 346 |
|
| 347 |
$Locker$ |
| 348 |
Name of the person who has a lock (usually no-one). |
| 349 |
eg. $Locker: tdb1 $ |
| 350 |
|
| 351 |
$Name$ |
| 352 |
Name of the tag. |
| 353 |
eg. $Name: release_1 $ |
| 354 |
|
| 355 |
$RCSfile$ |
| 356 |
Name of the RCS file. |
| 357 |
eg. $RCSfile: cvs-2.txt,v $ |
| 358 |
|
| 359 |
$Revision$ |
| 360 |
Revision number of the file. |
| 361 |
eg. $Revision: 1.3 $ |
| 362 |
|
| 363 |
$Source$ |
| 364 |
Full path to the file in the repository. |
| 365 |
eg. $Source: /usr/local/proj/co600_10/cvs/file.txt,v $ |
| 366 |
|
| 367 |
$State$ |
| 368 |
State of the file (?). |
| 369 |
eg. $State: Exp $ |
| 370 |
|
| 371 |
The keywords are automatically replaced by CVS, even if it's |
| 372 |
already been expanded. You just put it in and leave it be! |
| 373 |
|
| 374 |
Online CVS Resources |
| 375 |
-------------------- |
| 376 |
That about concludes my guide on the basics of CVS for the |
| 377 |
development work in the project. However, further resources |
| 378 |
can be found on the following webpage. I've learnt an awful |
| 379 |
lot from this "online book", and I'd recommend it to anyone |
| 380 |
wanting to get to grips with CVS. |
| 381 |
|
| 382 |
http://cvsbook.red-bean.com |
| 383 |
|
| 384 |
Also, the "home" of CVS, if there is such a thing. |
| 385 |
|
| 386 |
http://www.cvshome.org |
| 387 |
|
| 388 |
About |
| 389 |
----- |
| 390 |
This document was written by Tim Bishop [tdb1@ukc.ac.uk] for |
| 391 |
use by the team working on a 3rd year Computer Science |
| 392 |
project called "i-scream". More details can be found on the |
| 393 |
project website; |
| 394 |
|
| 395 |
http://www.i-scream.org.uk |
