The source code for Jikes RVM is stored in a Subversion repository. A developer can either work with the version control system or downloaded one of the releases.
Download a Release
Major and minor releases of Jikes RVM occur at regular intervals. These releases are archived in the file downloadarea in either tar-gzip (jikesrvm-<version>.tar.gz) or tar-bzip2 (jikesrvm-<version>.tar.bz2) format. Use your web browser to download the latest version of Jikes RVM then to extract the tar-gzip archive type:
> tar xvzf jikesrvm-<version>.tar.gz
or for the tar-bzip2 archive type:
> tar xvjf jikesrvm-<version>.tar.bz2
The source code for Jikes RVM is stored in a Subversion repository. There is plenty of online documentation for using Subversion such as the Subversion Book or Sourceforge documentation but after installing Subversion the current version of source can be downloaded via:
You can also retrieve a specific version (such as 2.4.6) via:
If you are a core developer you will be able to commit changes to the repository directly. Otherwise you will need to place patches in the patch tracker.
You can browse the online subversion repository at http://svn.sourceforge.net/viewvc/jikesrvm/rvmroot/trunk/.
You may want to retrieve Jikes RVM, make modifications and version control your changes. Unfortunately Subversion does not natively support decentralized development model where everyone maintains their own development tree. For this you will need to use SVK. SVK describes itself as "a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools."
Note: The directions on this page were partially derived from a blog entry by Scott Laird.
Setting up the Local Repository
After you have downloaded and installed SVK you need to initialize a local repository and import Jikes RVM into local repository.
Synchronization will take a long time (Jikes RVM has a lot of history to import) and may need to be restarted if there is problems with the sourceforge servers.
Setting up a Local Branch
After the remote repository has been synchronized you can setup a local branch where you will do all your work and check out a working copy.
SVK differs from Subversion in that the metadata for a checkout is not stored in the directory in which the files are checked out. You will not find any files such as ~/Research/jikesrvm/.svk/ - instead it is stored in central location. This means that if you ever want to move around a locally checked out copy you need to run:
And if you ever need to delete a locally checked out copy you delete the physical directory and then purge the record of its existence via:
Making Local Changes
You can modify the files in the checked out working copy and perform all the usual "svk commit", "svk diff" commands on the source code.
Merging with Upstream Changes
When changes occur in the upstream Jikes RVM subversion repository you can update your local repository via the command:
And you may want to move the changes across into your local branch via:
And update your local branch via:
Now that you have modified your local branch you want to create a patch so that it can be integrated back into the main Jikes RVM tree. The first thing to do is create a directory that will contain the patched versions.
Then you create a new branch for the patched version:
And merge across the changes you are interested in:
Note: the -l switch says to use the previous commit message as part of the new merge commit message.
You then check out the branch and verify your changes. By verifying your code against a clean tree you can make sure that you didn't miss any other changes in your local tree and that you didn't introduce any unintended changes. If you missed some changes you can add them directly to the branch or merge them across.
Finally you create a diff file and add it into the patch tracker.
If the main source moved further forward and you need to update your local branch you can do it via the following command. Then just retest and recreate the diff file.
If you are a Jikes committer and want to apply patch directly to the upstream source repository then you run:
Mirroring Local Branch
Sometimes you may want to mirror a local branch into a public Subversion repository. This may be so others can look at your changes, to provide a backup or to share changes between multiple SVK repositories.
You can update the mirror at anytime via:
While a central SVN repository is excellent for collaboration on a common code base, sometimes you wish to try things before commiting to the SVN repository. If you plan on making a lot of changes spread accross numerous files, it can be handy to have a local version control system (VCS) in which to record your changes. Similarly to the SVK setup detailed above, you can opt to use darcsas your local version control system. Darcs is an open-source distributed VCS. This means that there is no centralized server on which the repository resides. Instead, each repository stands on its own, and changes made to one copy of the repository can be put into another copy. Basically, darcs is built around patches, that are invertible, commutable (if not there is a dependency) and mergable in any order. Because people are pretty familiar wirth SVN, a there is a page detailing the workflow comparison between darcs and SVN.
The directions given here are structured alike the SVK directions.
Setting up a Local Repository
Once you have downloaded and installed darcs onto your machine, you can create the initial repository:
Make sure you have only the source files in your my_jikes_source_dir directory, as we will be automatically adding all source files to the darcs repository. Darcs ignores all CVS and SVN related files, as well as a host of other so called boring files. The list of boring files is kept in the prefs/boring file in your darcs repository. Feel free to expand this list.
If you give no other parameters, you get the following questions
You will only be asked for your email address the first time you check someting into the repository. After the initial checkin, you end up with a _darcs directory that contains all the relevant information about your repository.
Making Local Changes
If you edit files locally, have tested your changes (i.e., Jikes RVM at least builds), you may want to record them in your repository. First check to see that you will record what you think has been changed.
If you added files in the Jikes RVM tree, you may wish to use the --look-for-adds argument to whatsnew. There are no special issues when dealing with binary files. If you are satisfied you can record the changes to all changes files (optionally using the --look-for-adds flag).
Or you can only record the changes made to one or more file, by explicitly adding them to the command line
You can confirm each change, or confirm them all at once, by typing a when asked to record 'this' patch. Notice that the smaller patches will be congregated into the larger patch that will get a name and (optionally) a comment in the repository. You can rollback patches, undoing them in the repository, the local copy (i.e., the working copy), or both. A list with patches you have recorded is available.
Merging with Upstream Changes
If the Jikes RVM central SVN repository is changed, you use the regular SVN update to get the changes, and then you simply record the changes into the local darcs repository using
Preparing Patches and Applying Changes
If you wish to get a patch to the Jikes RVM team, you first update your local copy using SVN, store the changes into darcs, as described above, and basically create a SVN diff and submit the diff to the patch tracker.
If you have SVN write access to the central Jikes RVM SVN repository, you use the regular SVN command to check in your code.
Mirroring a Local Branch
Your darcs repository can be made available though HTTP or SSH. For the former, you place the _darcs directory on a public HTTP server, for the latter you need to give people SSH access to the machine your repository resides on. If you wish to take a copy of your repository along, you basically have two choices. Either you copy the full Jikes RVM source tree, inclusing your _darcs directory. This will allow you to keep track of the changes made in the central SVN repository while you are on the road. Or you only take your darcs repository along, relying on access to the machine on which the full Jikes RVM SVN checked out copy resides. For the latter you just 'get' your darcs repository. For the sake of clarity, we will call the machine you did all the above on the 'original_machine', and we will call the one where you want a copy on the 'road_machine'. On road_machine you
If you make changes while on the road, you record them locally, on road_machine. If you wish to sync with original_machine you
Suppose you have updated the working copy from the SVN repository on original_machine, and you wish these changes reflected on your road_machine, you first check the changes into darcs on the original_machine and then you
The darcs repositories with which you have synched are kept in _darcs/prefs/repos.
Use SVN::Mirror to Clone the SVN Repository
You can use SVN::Mirror to mirror the repository locally. You can install it via your distributions package manager or via Perl's CPAN (<code>perl -MCPAN -e shell</code>) installation tool. You will need the command line interface to this called svm.
First create a repository to hold your mirror that will be held at the location 'SVMREPOS':
then initialize and synchronize it to the latest repository:
Synchronization will take a long time (Jikes RVM has a lot of history to import) and may need to be restarted if there is problems with the sourceforge servers. You can speed up the sync by flattening a series of changes into one larger change via:
where $REVISION is the current revision.
Rsync the SVN repository
The following commands will copy the Jikes RVM SVN repository to the current directory: