| 1 |
tdb |
1.1 |
Using CVS (part 2) |
| 2 |
|
|
================== |
| 3 |
|
|
|
| 4 |
tdb |
1.2 |
Contents |
| 5 |
|
|
-------- |
| 6 |
|
|
- Errata to "Using CVS (part 1)" |
| 7 |
|
|
- Setting up CVS on a Public PC (with WinCVS/SSH) |
| 8 |
tdb |
1.3 |
- Setting up CVS off campus/SSB (with WinCVS/SSH) |
| 9 |
tdb |
1.2 |
|
| 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 |
tdb |
1.1 |
|
| 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 |
tdb |
1.3 |
|
| 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 |
tdb |
1.1 |
|
| 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 |
