You begin using Subversion by copying a directory from a remote repository to a local directory on your file system. This is known as a checkout of a working copy.

Subversion uses a copy-modify-merge model meaning that you can add and edit files and directories in your working copy like any other files on your system, but you should use subversion commands for everything else such as svn copy and svn move instead of the operating system commands.

Subversion commands can be run from a command shell such as Bash on Linux. The subversion client command is svn followed by optional sub-commands, options, and arguments.

Show the program version and modules

$ svn--version

Run a sub-command

$ svn<subcommand>[options][args]

Most sub-commands take file and/or directory arguments, recursing on the directories. If no arguments are supplied to such a command, it recurses on the current directory (inclusive) by default. (from svn help)

The following is only a partial list of sub-commands relating to this instruction. For a complete list, see the Subversion Book, or use svn help.

add - Schedule a new file or directory (including contained files) for inclusion in the repository

checkout, co - Create a local working copy of a remote repository

commit, ci - Commit (check in) local changes to the repository

copy, cp - Copy one or more files in a working copy or in the repository

delete, del, remove, rm - Items specified are scheduled for deletion upon the next commit. Working copy files not yet committed are deleted immediately.

There are instances where Subversion may need to open an editor. You need to have the environment variable EDITOR set to the editor you would like to use. To set it for the current terminal session in Bash (your path may differ):

Make changes - For this you may edit files in an editor, or use the svn add, svn delete, svn copy, svn-move commands

Review Changes - For this you use the svn status and svn diff

Fix Mistakes - Make additional edits to files or you can use the svn revert to restore files or directories to an unmodified state

Resolve Conflicts - There is a chance others have committed changes while you have been changing your working copy. You should run the svn update command to bring your copy up to date. This may create a local conflict where someone may have added a file with a name that you also want to add, or may have made changes to the same line of a file as you. For this use the svn resolve command.

The examples in the previous sections use a simple commit message with the "-m" option.

This is fine for some quick testing or for large bulk commits of code that you wrote.

We ask that your commits include special tagging to appropriately credit the patch.
See the crediting section of the Coding and Commit
Conventions of the Apache Subversion project.

Log comments are important.
Information like author, where the change start/ends, the date, the bugzilla issue, and the author don't really belong
in the code as SVN can keep it much more effectively without altering the coding style.
Always try to use a log file for your commits. The previous commit when done by an experienced committer
should actually look like this:

New development is done in the "trunk", development area, of the tree. Stable, release branches, are specifically named and can be found
in the branches area of the openoffice svn tree. With few exceptions you do NOT do direct commits to the stable, release,
branches. Changes, commits, to stable branch are typically only done during a formal release cycle and must be discussed on the "dev" list.

When a new release is in preparation, bug fixes are reviewed, and fixes that have been made to "trunk" get applied to the stable, release, branch. This is done using the "svn merge" command which finds previous changes and replays them. SVN also keeps a record
of the specific commits that have been merged so the changes are much easier to track down.

The first step is to do a check out of the stable, release, branch. The following examples use the AOO34 release branch, and assume
you want to apply changes from trunk for a new release, maybe AOO341.

You can do a complete checkout of the release branch or you can save some space by using the "--depth=empty" option:

Apache and the Apache feather logos are trademarks of The Apache Software Foundation.
OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation.
Other names appearing on the site may be trademarks of their respective owners.