SubversionInEclipse

Tutorial: Subversion in Eclipse

This tutorial will explain how to use Subversion in Eclipse. Tigris offers a very useful plug-in for Eclipse called Subclipse which provides an easy-to-use user interface to Subversion. Several Subversion tasks are explained on this page. Before continuing, please make sure:

• you have downloaded and installed Java 5.0 (the JRE suffices);
• you have downloaded and installed Eclipse 3.1 or later;
• you have downloaded and installed Subclipse (this is done from within Eclipse; see link for a tutorial).

This tutorial uses Java 1.5.0_04, Eclipse 3.1 and Subclipse 0.9.34. If you use different versions, messages described in this tutorial might be different, but you should still be able to follow all steps.

Note: most larger lab rooms in the BBL already have all this installed.

Checking out the Cheetah project

One of the phrases common in the world of version control systems is 'check out'. A check out of a repository is usually done only once, and it copies the latest version of (a part of) the repository to your local hard disk. This is the first thing to do if you want to contribute to the Cheetah software.

To check out a project using Subclipse, do the following:

• Open the SVN perspective: from the menu bar, choose Window -> Open Perspective -> Other..., select SVN Repository Exploring and press OK.
• Add the Cheetah repository: right-click in the SVN Repository view and select New -> Repository Location.... Enter https://www.aardrock.com/repos/cheetah/ as the Url and enter your SVN username and password. Press Finish. The location will appear in the view.
• Check out the Cheetah project from within the Cheetah repository: expand the repository location. Expand the folder called trunk. A folder called Cheetah will appear. Right-click this folder and select Check Out As Project.

Running Hello World

• Switch to the Java perspective: from the menu bar, select Window -> Open Perspective -> Other..., select Java and press OK. Note the Cheetah project in your Package Explorer.
• In the Package Explorer, expand Cheetah -> src -> (default package). Right-click !HelloWorld.java and select Run As -> Java Application. Voila! You have successfully checked out the project and run the application.

Committing changes

• Now change the !HelloWorld class: open it and add a print statement that prints out something with your name in it. Save.
• In the Package Explorer, right-click !HelloWorld.java and select Team -> Commit....
• Enter a useful commit comment. In this case, something like "Added my print statement!!" will suffice. This message will be seen by all other Cheetah members when they download your changes. Make sure the checkbox in front of !HelloWorld.java is selected and press OK.

Now, when other people do a check out or update of the project, they will see your changes.

Updating the project

In Subversion, updating means that you ask Subversion to check for newer versions of files in the repository. If other people have committed changes, updating will copy these changes to your local hard disk. An update is different from a check out in that only the changed files are copied instead of the whole project. This matters especially when the project gets bigger.

When other people have done this tutorial and added their print statements, you can update your version to see these changes. In the Package Explorer, right-click the Cheetah project and select Team -> Update. The whole project will be updated.

Resolving conflicts

Imagine this happens:

• User 1 updates !HelloWorld.java
• User 2 updates !HelloWorld.java. Both users have the same version now.
• User 1 modifies !HelloWorld.java.
• User 2 modifies !HelloWorld.java, independently of User 1. Both users are working on their own computer, with their own local copy, and don't know about each other that they're both working on the same file.
• User 1 is done and commits his changes to the repository.
• User 2 is done and commits his changes to the repository.

Obviously, this can't happen just like that. What happens now? Does User 2 override User 1's changes? No. This is where the version control system is at its most powerful: User 2 will get a message that !HelloWorld.java has changed in the repository while he was editing his local copy. It is now User 2's responsibility to merge his and User 1's changes in such a way that the new !HelloWorld.java incorporates both changes. For example, if both User 1 and User 2 added their own print statements, User 2 should make sure that the final version has both of these print statements. The user interface provides help by showing the differences between the new !HelloWorld.java on the repository and User 2's version of !HelloWorld.java. When User 2 is done, he commits the file for real.