Version Control on the CS Systems

All of the CS Linux clients have at least the following Version-Control System (VCS) software installed:

If you're unfamiliar with version control, you are encouraged to read about each program to decide what's best for you. Git is probably a good default choice; it's what the vast majority of open source software projects use.

Using a VCS Yourself

If you want to manage your own files, you can use any of the version control programs directly on our systems; you don't need to use a server of any kind.

Bazaar, Darcs, Git, and Mercurial are all distributed version control systems and are designed to work without requiring a central repository. Working with them is as simple as changing to the directory where your files are (or will go) and initializing a new repository there. That looks something like this: 

$ cd ~/my-project
$ bzr init    # For Bazaar
$ darcs init  # For Darcs
$ git init    # For Git
$ hg init     # For Mercurial

After that, you can work with your files and commit them to the repository as you like.

CVS and Subversion are centralized version control systems and, as such, need to have a separate repository, even if only one person will be working on it. You will need to designate a subdirectory of your home directory as your Subversion or CVS repository in addition to the directory where you will be working with your files.

For Subversion, that looks something like this: 

$ svnadmin create ~/my-repository
$ svn mkdir --parents -m 'Create my project.' file://${HOME}/my-repository/my-project/trunk
$ svn checkout file://${HOME}/my-repository/my-project/trunk ~/my-project
$ cd ~/my-project

For CVS, it looks like this: 

$ cvs -d ~/my-repository init
$ cd ~/my-project
$ cvs -d ~/my-repository import -m 'Create my project.' my-project $USER start
$ cd ~
$ mv ~/my-project ~/my-project-original  # or rm -r ~/my-project
$ cvs -d ~/my-repository checkout my-project

Note that the use of CVS is not really recommended unless you have a specific need for it. Subversion is generally an easier system to work with, and many people find that the distributed version control systems are better for them than either Subversion or CVS.

Using a VCS Remotely

You can keep a checkout of your files on other computers (like your personal desktop or laptop) and still commit changes to the repository you set up on the CS systems. Although remote access will work through any of the Linux clients, we suggest that you use gradx on the Grad/Research network and ugradx on the Undergrad network.

Assuming you're on the Grad/Research network, for a project in ~/my-project with an account name of your-account, here are the repository URLs you would use with each DVCS:

Bazaar
bzr+ssh://your-account@gradx.cs.jhu.edu/~/my-project
Darcs
your-account@gradx.cs.jhu.edu:my-project
Git
ssh://your-account@gradx.cs.jhu.edu/~/my-project
Mercurial
ssh://your-account@gradx.cs.jhu.edu/~/my-project

For Subversion, you would use svn+ssh://your-account@gradx.cs.jhu.edu/users/your-account/my-project. Note that home directories on the Undergrad network are in /home, not /users. NOTE: svn+ssh:// URLs will only work for personal projects. If you have set up a collaborative environment as detailed on our Hosting Subversion Repositories page, the URL would be https://www.cs.jhu.edu/~your-account/svn/my-project.

For CVS, you would use :extssh:your-account@gradx.cs.jhu.edu:/users/your-account/my-project, with the same caveats about home directories as mentioned for Subversion. NOTE: CVS at CS is currently only supported for personal repositories, not collaborative ones.

Using a VCS with Other People (Hosting Your Code For Public Access)

The CS department does not currently provide a centralized repository service for use by faculty and students, although that might change in the future. Fortunately, it's not too hard to use your home directory and your CS website to facilitate collaboration with others, especially if you're using a distributed version control system.

The essence of this approach is that you have a repository that's shared with others through your website. They pull from your repository and make changes locally on their systems. When those changes are ready to be integrated into your repository, either you pull from other people's web-shared repositories or they send you changesets that your version control system can integrate.

For each of the examples below, we will assume that the project name is "my-project", that you will be editing its files in the ~/my-project directory, and that the URL for others to access it will be https://www.cs.jhu.edu/~your-account/my-project.

(Note that on the Undergrad network, you would connect to ugradx instead of gradx; your home directory would be /home/your-account, not /users/your-account; and the URL would be https://www.ugrad.cs.jhu.edu/~your-account/my-project, not https://www.cs.jhu.edu/~your-account/my-project.)

Bazaar

From your project directory, use bzr push to make a public repository in your webspace: 

$ mkdir ~/public_html/my-project
$ cd ~/my-project
$ bzr push --no-tree ~/public_html/my-project

The public branch will just be the repository; it will not have files that you can edit in it. When you make changes to your private repository (in ~/my-project), you will have to periodically re-run bzr push to make those changes visible to others.

Other people can get their own checkouts from your public branch: 

$ bzr branch https://www.cs.jhu.edu/~your-account/my-project
$ cd my-project

When you want to pull in other people's changes, you can either pull from their public repositories: 

$ cd ~/my-project
$ bzr merge https://other.server.edu/path/to/their/repo

Or they can send you a merge directive, which you then merge.

They would run: 

$ bzr send -o /path/to/directive.patch https://www.cs.jhu.edu/~your-account/my-project

Then they would send you the merge directive and you would run: 

$ cd ~/my-project
$ bzr merge /path/to/directive.patch

Darcs

With Darcs, the recommended way to publish your repository is simply to make a symbolic link to it from your webspace: 

$ ln -s ~/my-project ~/public_html/my-project

People can then get a copy of your repository with: 

$ darcs get https://www.cs.jhu.edu/~your-account/my-project

When you want to pull in other people's changes, you can either pull from their public repositories: 

$ darcs pull https://other.server.edu/path/to/their/repo

Or they can send you a merge directive, which you then merge.

They would run: 

$ darcs send https://www.cs.jhu.edu/~your-account/my-project

After you receive the changeset, you would merge it with: 

$ cd ~/my-project
$ darcs apply /path/to/changeset

Git

Git uses git clone to create the public repository initially: 

$ git clone --bare ~/my-project ~/public_html/my-project.git
$ cd ~/my-project
$ git remote add public ~/public_html/my-project.git

As you make changes to your repository, you will need to periodically push those changes to the public repository so others can see them: 

$ cd ~/my-project
$ git push public

Others can get a copy of your repository with: 

$ git clone https://www.cs.jhu.edu/~your-account/my-project.git

When you want to pull in other people's changes, you can either pull from their public repositories: 

$ cd ~/my-project
$ git pull https://other.server.edu/path/to/their/repo.git

Or they can send you patches from git.

They would run: 

$ git format-patch origin

After you receive the patch files, you run: 

$ cd ~/my-project
$ git am /path/to/changes.patch

Mercurial

Mercurial uses hg clone to create a new repository: 

$ hg clone -U ~/my-project ~/public_html/my-project

As you make changes to your repository, you will need to periodically push those changes to the public repository so others can see them: 

$ cd ~/my-project
$ hg push ~/public_html/my-project

Others can get a copy of your repository with: 

$ hg clone https://www.cs.jhu.edu/~your-account/my-project

When you want to pull in other people's changes, you can either pull from their public repositories: 

$ cd ~/my-project
$ hg pull https://other.server.edu/path/to/their/repo

Or they can send you patches.

They would run: 

$ hg outgoing -p https://www.cs.jhu.edu/~your-account/my-project >/path/to/changes.patch

After you receive the patch files, you run: 

$ cd ~/my-project
$ hg import /path/to/changes.patch

Subversion

The setup for collaboration using Subversion on CS systems is rather complicated. If you're familiar with one or more of the distributed version control systems, you're probably better off using one of them instead.

Nevertheless, if you need to use Subversion, instructions for doing so are on our Hosting Subversion Repositories page.

CVS

CVS does not support using HTTP as a transport, so it's not currently supported for collaboration, though personal projects will work just fine. If you need to use CVS to collaborate with other people, please email support@cs.jhu.edu for assistance.

Non-CS Hosting

There are various websites on which you can host repositories under various conditions. The ones listed here are for your information; we don't endorse or recommend any particular service.

GitHub has educational accounts aimed at students working on class projects and at teachers providing repositories for their students. These accounts support a limited number of private repositories, so your data is not explicitly shared with the world. (It is, however, hosted on servers not under the direct control of Johns Hopkins.)

GitLab has free accounts with an unlimited number of private repositories.

Sourcehut is a minimal lightweight hosting platform with support for both Git and Mercurial, in both public and private repositories. It's a paid service, but on a more-or-less pay-what-you-can-afford honor system. Hosting fees may be waived entirely if you contact them and explain why you can't afford the service at the moment.