Committing Changes

Once the edits are complete and have been verified to work correctly, it is time to publish them so others can view the changes.

For each file in the working copy, SVN records two pieces of information:

The file's working revision that the current working file is based on.

A timestamp recording when the local copy was last updated by the repository.

Using this information, SVN sorts the working copy on the local system into four categories:

Unchanged; current

The file in the working directory is unchanged and matches the copy in the repository, meaning no changes have been committed since the initial check out. Both svn commit and svn update will do nothing.

Locally changed; current

The file in the working directory has been edited but has not yet been committed to the

repository, and the repository version has not been changed since the initial checkout. Running svn com m it will update the repository with the changes in the working directory; running svn update will do nothing.

Unchanged; out of date

The file in the working directory has not been edited, but the version in the repository has, meaning that the working copy is now out of date. Running svn commit will do nothing;

running svn update will merge the changes in the repository with the local working copy.

Locally changed; out of date

The file in both the working directory and the repository has been changed. If svn commit is

run first, an 'out-of-date' error will occur. Update the file first. Running svn update will attempt to merge the changes in the repository with those on the working copy. If there are conflicts SVN will provide options for the user to decide on the best course of action to resolve them.

Running svn status will display all of the files in the working tree that do not match the current version in the repository, coded by a letter.

? item

The file is not recognized by SVN; that is it is in the working copy, but has not yet been added to the repository, or been scheduled for any action.

A item

The file is scheduled for addition to the repository and will be added on the next commit.

C item

The file is in conflict with a change made on the repository. This means that someone has edited and committed a change to the same section of the file currently changed in the working copy, and SVN does not know which is 'correct'. This conflict must be resolved before the changes are committed.

D item

The file is scheduled for deletion on the next commit.

M item

The file has been modified and the changes will be updated on the next commit.

If the --verbose (-v) is passed with svn status, the status of every item in the working copy will be displayed, even those that have not been changed. For example:

$ svn status -v M 44 23 sally README 44 30 sally INSTALL M 44 20 harry bar.c 44 18 ira stuff

44 35 harry stuff/trout.c D 44 19 ira stuff/fish.c 44 21 sally stuff/things A 0 ? ? stuff/things/bloo.h 44 36 harry stuff/things/gloo.c

Along with the letter codes, this shows the working revision, the revision in which the item was last changed, who changed it, and the item changed respectively.

It can also be useful to see which items have been modified in the repository since the last time a checkout was performed. This is done by passing the --show-updates (-u) with svn status. An asterisk (*) will be displayed between the letter status and the working revision number on any files that will be updated when performing an svn commit.

Another way to view changes made is with the svn diff command. This displays changes in a unified

diff format, describing changes as 'snippets' of a file's content where each line is prefixed with a character: a space for no change, a minus sign (-) for a line removed, and a plus sign (+) for an added line.

Occasionally a conflict will occur. SVN provides the three most common responses (postpone, diff-full, and edit) and a fourth option to list all the options and what they each do. The options available are:

(p) postpone

Mark the conflict to be resolved later.

(df) diff-full

Display the differences between the base revision and the conflicted file in unified diff format.

(e) edit

Change merged file in an editor.

(r) resolved

Accept the merged version of the file.

(mf) mine-full

Accept my version of the entire file, ignoring the most recent changes in the repository.

(tf) theirs-full

Accept their version of the entire file, ignoring the most recent changes in the local working copy.

(l) launch

Launch an external tool to resolve conflict (this requires set up of the chosen external tool beforehand).

(h) help

Displays the list of options as detailed here.

Finally, provided the project has been changed locally and any conflicts have been resolved, the changes can be successfully committed with the svn commit command, appending the option -m:

$ svn commit filename -m"Fixed a typo in filename"

Sending filename

Transmitting file data . Committed revision 57.

$

As can be seen above, the -m option allows a commit message to be recorded. This is most useful when the message is meaninful, which in turn makes referring back over commits straightforward.

The most updated version is now available for anyone with access to the repository to update their versions to the newest copy.