12 cvs mauro jaskelioff (originally by gail hopkins)
TRANSCRIPT
12 CVS
Mauro Jaskelioff(originally by Gail Hopkins)
Introduction
CVSWorking with an existing CVS
moduleCreating your own CVS module
Diff
Computer Science has developed algorithms that can automatically detect the changes to a file - especially text files
One such algorithm is encapsulated in a UNIX tool call diff
Diff Example
world1.cc
int main( ) { printf(“hello world”);}
world2.cc
int main( ) { printf(“Hello World!”);}
Diff Example (2)
$ diff world1.cc world2.cc2c2
< printf(“hello world”);
---
> printf(“Hello World!”);
More on Diff
Command line - diff file1 file2 “show me how to change file1 into file2”
Output Displays the ed commands needed to
change file1 into file2 2c2
Change line 2 in file1 into line2 of file2
CVS: Concurrent Versions System
Many version control systems exist, CVS is one of them
Not the best but open source and installed in unnc-cslinux. Also available in most Linux distributions and widely used.
CVS is a backward delta system
Copy-Modify-Merge
From last lecture:1. A developer copies the version of the
system in which they are interested into their own filespace
2. They then make any changes they want3. This is then merged back into the central
version4. CVS uses “version tracking” to manage
multiple users
Working with an Existing set of Source Code
You need to set the environment variable $CVSROOT for the location of the CVS repository
You then type cvs checkout module. This will create a directory with the module name in your filespace. This directory will contain the current state of all the source code
Working with an Existing set of Source Code (2)
You can type cvs checkout -r tag module to get the version of the system with the specified tag
You can then change files at will.
Committing Changes
cvs diff -c will show you what changes you have made
cvs commit filenames will place all your changes in the repository. If you miss out filenames then it will commit everything in your current directory and all its subdirectories
You will be prompted to enter a description of your change
Merging Changes
If another user has made changes since you checked out the files then cvs commit will fail with an Up-to-date check error
Use cvs update -d to get hold of the other developer’s changes
Conflict Resolution
From last lecture: With a version tracking system there has to
be a mechanism for deciding what to do if two developers have changed the same file
CVS uses diff to manage as much of this automatically as possible
If changes overlap badly though, you will get a merge conflict which has to be resolved by hand
Resolving Conflicts
In the partially merged version you will find:
You can then edit these together
<<<<<< filenameyour changes here======committed changes here>>>>>> version number of file
Example: Using CVS
[person1]$ export CVSROOT=/home/
[person1]$ cvs checkout cvstest
cvs checkout: Updating cvstest
U cvstest/world1.cc
[person1]$ ls
cvstest
[person1]$ cd cvstest
[cvstest]$ ls
CVS world1.cc
[cvstest]$
Person 1 Edits world1.cc
int main( ) { printf(“hello world”);}
int main( ) { printf(“Hello World!”);}
Person 1 commits Changes
$ cvs commit
cvs commit: Examining .
Checking in world1.cc;
/home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc
new revision: 1.2; previous revision: 1.1
done
Person 2 gets a Copy
$ ls
$ cvs checkout cvstest
cvs checkout: Updating cvstest
U cvstest/world1.cc
Example: Person 1 makes a change
/* This is a comment added by Person 1 */
int main( ) { printf(“Hello World!”);}
Example: Person 2 makes a change
int main( ) { printf(“Hello World!”);}
/* This is a comment added by Person 2 */
Person 1 Commits their Change
$ cvs commit
cvs commit: Examining .
Checking in world1.cc;
/home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc
new revision: 1.3; previous revision: 1.2
done
…then Person 2 tries to Commit their Change
$ cvs commit
cvs commit: Examining .
cvs commit: Up-to-date check failed for ‘world1.cc’
cvs [commit aborted]: correct above errors
Person 2 Updates their Version
$ cvs update -d
cvs update: Updating .
RCS file: /home/mjj/cvs/cvstest/world1.cc,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into
M world1.cc
Person 2’s Version of world1.cc
[cvstest]$ less world1.cc
/* This is a comment added by Person 1 */
int main( ) { printf(“Hello World!”);}
/* This is a comment added by Person 2 */
Person 2 attempts to Commit
[cvstest]$ cvs commit
cvs commit: Examining .
Checking in world1.cc;
/home/mjj/cvs/cvstest/world1.cc,v <-- world1.cc
new revision: 1.4; previous revision: 1.3
done
Person 1 makes more changes
Person1 checks out the last version and modifies the file
And then succesfully commits the changes.
/* This is a comment added by Person 1 */
int main( ) { printf(“Hello World - Hello!”);}
/* This is a comment added by Person 2 */
Person 2 makes more changes
/* This is a comment added by Person 1 */
int main( ) { printf(“Hello World!”);}
/* This is a comment added by Person 2 */
This time when Person 2 Updates…
$ cvs update -d
cvs update: Updating .
RCS file: /home/mjj/cvs/cvstest/world1.cc,v
retrieving revision 1.4retrieving revision 1.5Merging differences between 1.4 and 1.5 into
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in world1.cc
C world1.cc
World1.cc with Conflicts in it
/* This is a comment added by Person 1 */
int main( ) {
<<<<<<< world1.cc
printf(“Hello World!”);
=======
printf(“Hello World - Hello!”);
>>>>>>> 1.5
}
/* This is a comment added by Person 2 */
More CVS Commands
cvs init initialises $CVSROOT to act as a repository
cvs import directory vendor release creates a new repository in $CVSROOT called directory. It puts everything in your current directory into the repository
cvs export checks a versions out of CVS without all the additional directories. This can be used for a release of the code
More CVS Commands (2)
cvs add filename schedules a new file to go into the repository
cvs delete filename schedules a file to be removed from the repository (N.B. You must already have deleted it from your filespace)
man cvs will show you a lot more commands - for viewing the log files, changing the version number tags and creating branches
CVS won’t Solve Everything!!
Projects need a policy for what happens if someone commits “broken” code to the repository. Most often people have forgotten to add files
If lots of people are working on the same file at once it can cause headaches when merging. Projects should try and organise themselves so that most of the time people work on different files
CVS won’t Solve Everything!(2)
What constitutes an acceptable log message?
Who is allowed to edit a file?Updating and Committing has to
happen regularly for CVS to work properly
Renaming files is problematic