Abstract
Centralized version control stores the history of the code base on a separate server from which copied can be provided to all developers.
In this lesson we will look at the advantages of centralized version control over local control. Particular attention will be paid to the area of collaboration where local locking mechanisms are replaced by after-fact detection and resolution of conflicting changes.
We will look at one of the most influential version control systems, CVS.
Centralized Version Control
rcs kept its repository of history information in the “live” working directories.
Each directory of a project had a separate repository.
Sharing among team members relied on the rather limited Unix protection scheme.
Centralized version control systems keep a project repository in a location separate from the programmer’s work area.
Allows one repository to track a project’s entire directory tree
Encourages/requires use of a network-based sharing scheme
Based on rcs
Uses a centralized store
Check-in and check-out are similar to rcs
By default, scope of commands is an entire directory tree
cvs checkout projectRootDir
makes a copy of projectRootDir in the working directory, checking out the most recent version of everything in the project.
Similarly,
cd projectRootDir
cvs commit -m "Added unit tests"
checks in any changes from the working directory on down.
cvs doSomething
commands as if they werefind . -type f -exec rcsDoSomething {} \;
Where’s the Repository?
The earlier commands presume that we have, somehow, already established a connection with the repository.
Local CVS Repositories
If the repository is on a local file file system,
-d
:cvs -d /usr/local/cvsroot checkout myProject/projectRootDir
or record this info in an environment variable:
setenv CVSROOT /usr/local/cvsroot
cvs checkout myProject/projectRootDir
Remote Repositories
The same techniques (-d, CVSROOT) can be used to specify remote repositories.
Instead of simply specifying the path to the repository, give
[:method:][[user][:password]@]hostname[:[port]]/path/to/repository
Usually, use
cvs login
to open a session (rather than get prompted for a password on every command).
Connection method: pserver
The pserver method is a built-in network connection method with password control.
Falling out of favor
pserver Exmaple
sirius:~/temp/tmp> setenv CVSROOT :pserver:zeil@cvs.cs.odu.edu:/home/cvs/dlib
sirius:~/temp/tmp> cvs login
Logging in to :pserver:zeil@cvs.cs.odu.edu:2401/home/cvs/dlib
CVS password: *****
sirius:~/temp/tmp> cvs checkout AlgAE
cvs checkout: Updating AlgAE
U AlgAE/.project
U AlgAE/AlgAE_layout.odg
U AlgAE/LICENSE.txt
U AlgAE/README.txt
U AlgAE/build.xml
U AlgAE/buttons.gif
U AlgAE/buttons.odg
U AlgAE/jhbasic.jar
U AlgAE/junit-4.10.jar
cvs checkout: Updating AlgAE/AlgAE_screenshot.png
⋮
sirius:~/temp/tmp> ls -ld AlgAE
drwxrwxr-x 11 zeil faculty 1024 Feb 21 13:39 AlgAE/
ssh Connections
If you have ssh access to the machine running the CVS server, you can do
sirius:~/temp/tmp> setenv CVSROOT :extssh:zeil@cvs.cs.odu.edu:/home/cvs/dlib
sirius:~/temp/tmp> cvs checkout AlgAE
The authenticity of host 'cvs.cs.odu.edu (128.82.4.233)' can't be established.
RSA key fingerprint
⋮
Password:
The History Commands
checkout: gets an initial copy of what’s on the server
update: checks to see if something newer than a local file copy is on the server, and if so, replaces the local copy by the remote one
commit: sends any local files that are newer than the server copy to the server as new revisions
add: places files that are not currently being tracked by CVS under version control
import: places a directory tree under version control
release: detaches the directory from the CVS server (if no files need to be committed)
Eclipse includes CVS support in its normal distributions.
From Window->Open Perspective->Other...
, select CVS Repository Exploring
Of course, you will need to have access to a repository before you see anything.
Checking Out an Existing Project
Pulling an existing project from CVS into Eclipse is pretty straightforward:
Eclipse Integration: Creating a Project
To add a new project to an existing repository:
Set up the project as normal on your local machine
Right-click on the project and select Team->Share Project...
You will eventually be shown a list of files to be committed.
Working with History in Eclipse
Right-click on a file or directory and look in the “team” menu
Add to version control
Commit…
Update
Synchronize with repository
You might want to put .cvsignore under version control.
Tag (name)
Show History
Examining History in Eclipse
Right-click on a file or directory and look for
Branches
rcs
Creating Branches
Make sure that you have checked in all the latest changes in your current working project.
Right-click on the project root directory and select Team <span>⇒</span> Branch\dots
.
Enter a name for your branch.
Leave “Start working in the branch” checked. Click OK.
All the files under that root directory will be marked as belonging to a new branch.
As you work on this branch, you can make frequent use of the Compare With ... Head
option to check for changes in the main trunk that you might want to incorporate into your branch code.
Merging a Branch Back Into the Main Trunk
Right-click on a project with an up-to-date copy of the branch, and select “Team ⇒ Tag as Version … ”
1: To begin the actual merge, start with an up-to-date copy of the main trunk (HEAD).
That should not be a problem, since you made sure that you had checked in all changes in the 1st step. But it is a bit disconcerting, so I prefer to simply work from s separate project that is already checked out from the HEAD branch.
You might consider placing a “tag” on the main branch (HEAD) to mark the spot on the branch just prior to the merge. that way, if you make a mistake when resolving conflicts (see below), it will be easy to get back to the current version. To place a tag, right-click on a project with an up-to-date copy of the HEAD, and select “Team ⇒ Tag as Version … ”
2: Right-click on the HEAD project and select “Team ⇒ Merge … ”.
3: CVS will compare the checked-in copy of the branch against the files in your local HEAD project.
This is not a commit of the merged changes to the HEAD branch.
4: Having resolved all changes, you now have a local copy of the project, associated with the HEAD branch in CVS, with a merged copy of code from the former HEAD and from the other branch.
Resolving Conflicts
During synchronization, changes are categorized as
These presumably need to be updated
.
These presumably need to be committed
.
These presumably need to be merged
The Conflict Editor
It allows you to view the differences between the two versions and decide whether
You can save the merged file and then “Mark as Merged”, which moves it from the “Conflicts” status to “Outgoing”
Or you can “Override and Update”, which indicates that you are abandoning your local changes and changing the file’s status to “Incoming”
Subversion
Subversion (a.k.a. svn) is a later version control system based on the same centralized model as CVS.
For the most part, working with it is not all that different from CVS.
It rose to popularity in the open source community in part because of some useful tools for making read-only versions available on the web.
Differences between CVS and Subversion w.r.t. history:
Subversion uses simpler revision numbers
Subversion tracks file and directory creation, deletion, renaming
Subversion does not implement a distinct mechanism for branching.
Each revision (and each checked-out local copy) “knows” its parent revision number.
Revisions can be checked out into distinct local directories from where their parents were located.
Remember – Subversion tracks moving/renaming of files
… but it Does Branches Anyway
“Branches” are kept in a separate directory from the trunk.
“Merging” is a general operation between revisions
Is This an Improvement?
I can’t decide if Subversion’s approach to branches is inspired or lazy.
The two are not, of course, mutually exclusive.
Branching and merging is CVS is just complicated enough that it’s easy to mess up.
In svn, you typically check out the trunk or a branch – not the whole repository.
No real differences between CVS and SVN
has to be installed as a plug-in
Relies on some non-Eclipse libraries that must be installed separately.
Sometimes a period of instability after Eclipse updates before either plugin becomes usable.
Google for instructions on either plugin