Search/Navigation:
Related:
SLAC/EPP/HPS Public
Jefferson Lab/Hall B/HPS Run Wiki
S30XL-LESA/LDMX
This page includes explanations of terms and commands for Subversion / SVN.
remote repository - the remote copy of the code etc. maintained by the Subversion server
repository root - the base URL of the repository such as svn://svn.freehep.org/hps/
structure node - any part of the repository under the root, which can be conceptualized as a directory on a file system, with the repository root as the "/" or root directory.
working copy - your copy of an SVN module including local changes
revision - a globally unique number to the repository tagging the state of the repository after a commit (including add, delete, etc.)
commit - push your changes to the repository, making a new global revision
revision - a global revision number tagging the state of the repository after a commit.
trunk - the remote repository's current revision, similar to "HEAD" in CVS terminology
tag - a copy of the trunk from some certain point in time, which should not be modified once created; usually kept in a node called 'tags'
branch - a fork of the trunk (or some other version of the code) which is for development and can be modified after it is created; usually kept in a node called 'branches'
merge - combining together two copies of (usually) the same node in order to merge their changes
All commands below assume that you are in a command shell like bash on Linux and that the current working directory is a local working copy of a structure node that has been checkout out of the repository.
svn co svn://repo/some/dir
This command will print out general repository information like your current revision # and the repository root.
svn info
Check the status of your local working copy
This command will list all your changes and additions in the local working copy:
svn status
Each file will have a letter next to it, such as:
M = locally modified
? = not tracked by Subversion
A = added
D = deleted
etc.
Check the SVN docs for a full list of all these commands.
svn ls some/relative/path/
or
svn ls svn://repo/some/path/
svn up
This command can be used to add files:
svn add rel/path/to/file1 rel/path/to/file2
These will then be pushed to the remote repository when you execute a commit.
Delete files from the repository
This command can be used to delete files:
svn rm rel/path/to/file1 rel/path/to/file2
The deletion will occur when you commit.
This command is used to commit your local changes to the repository:
svn commit -m "committing some stuff" [optional/path/to/file1] [optional/path/to/file2]
The list of files or directories to commit is optional, but it is usually a good idea to include it.
svn cp src/dir/or/file target/dir/or/file
svn mkdir path/to/dir
Be careful when using 'svn add' and 'svn commit' without any arguments, either from the command line or from the top-level in your IDE e.g. the infamous Team > Commit from an Eclipse project. This may cause many files to be added to the repository that should not be tracked and will need to be removed. Once a file is added, it is tracked 'forever' by the repository and not deleted, even though it might be removed in the trunk.
When executing more complex commands such as 'svn merge' use the '--dry-run' argument like 'svn --dry-run merge' to see what will happen without the command actually being executed.
Do not be too dependent on the IDE for using Subversion. Make sure to have a compatible SVN command line client available e.g. where the SVN minor version number is the same as your IDE's "connector" version (Eclipse), so that you are able to execute shell commands.
At the beginning of the work day, do an 'svn up' in order to synchronize your working copy with the repository. This will make sure you do not cause conflicts by modifying a file that someone has already made changes to in the repository.
Do not develop code in your working copy for an extended period of time without committing it, provided that checking it in does not cause a compilation or test case failure. This is especially true if there is the possibility that someone else is working on the same file.