From AardRock Wiki
Jump to: navigation, search

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:

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 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 ! 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 ! 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 ! 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 !
  • User 2 updates ! Both users have the same version now.
  • User 1 modifies !
  • User 2 modifies !, 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 ! 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 ! 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 ! on the repository and User 2's version of ! When User 2 is done, he commits the file for real.