Typical work cycle: Edit, Update, Commit

Often with SVN (and most other SCM systems), once you have checked out your project, or shared it, you work in a simple cycle:


  1. Edit
  2. Update
  3. Commit

The SVN plug-in for Eclipse makes working with this cycle easy by combining the Team features in Eclipse with the special features in SVN.

Editing your working copy

When editing your working copy, you can observe the markings on the resource (i.e. file, folder, etc.) found in the Navigator view (and views that are based on the same information, like the Java Development Tools' Package Explorer.)

Eclipse will catch your changes and refactorings, as long as you use Eclipse to work with your working copy. You may contrast this with working with the SVN command line tool which needs to perform about every rename, delete and move operation that you want in the working copy. The SVN plug-in for Eclipse does this for you.

One exception from this is adding resources: The new file(s) or folder(s) you create must be added to your working copy, using the command Add to Source Control found in the "Team" menu available in the context menu for the added resource(s). If you do not do this, the SVN plug-in will display a question mark (?) next to the resource, meaning that an unknown file is present in your working copy. Once added however, the resource is marked with an asterisk (*)

Eventually, when you commit your changes, this marking will disappear. If you forget to add a resource, it will still be presented in the commit dialog, but will be de-selected by default.

To ensure exclusive access when editing a file, you may lock it if your repository is based on SVN 1.2 or later.

Updating your working copy with other people's committed changes

While your are working, editing, debugging, etc., others (if you are working in a team) may commit changes to the project. To keep up, you have to update whenever you are ready to do so, e.g. when your changes are stable. You should also always update immediately before your commit your work.

Should an update concern one of the resources that you had modified, SVN will try to merge those changes. This will work if your changes do not overlap the changes made in the repository, but in case of a conflicting change, the affected resources in your working copy are marked as being conflicted, and some text markings are placed, citing the differences between the repository and your changes. These conflicts can be mended manually, or by using the Edit conflicts command found in the Team menu. If you resolve the changes by editing the text, you need to mark the conflict as resolved.

In extreme cases it may be simpler to revert your own changes and start over.

Committing your changes to the repository

Once you are pleased with all your changes, it is time to commit them to the repository. SVN will never let you commit changes that are out-of-sync, and will force you to update in the event of a collision, but this only covers the cases when the affected resources require updating. However, if a dependent resource (for instance, a program file which is required by your change) is updated, this will not be detected when committing. This is why you need to update first and review your change.