# Typical work cycle: Edit, Update, Commit

Often with Subversion (or 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

Subclipse makes working with this cycle easy by combining the Team features in Eclipse with the special features in Subversion.

## 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 Subversion command line tool which need to be told about every rename, delete and move operation that you do in the working copy. Subclipse 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, Subclipse 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.

## 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, Subversion 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. Subversion will never let you commit changes that are out-of-sync, and will force you to update in the event of a collision (TODO: get new image of this), 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.

### Reference:

Team > Update
Team > Commit
Team > Add to Version Control
Team > Edit conflicts
Team > Edit conflicts
Team > Mark Resolved