Page History

...

Most of the arguments used for these example commands are completely bogus and, depending on the command, should be replaced by valid paths to files in your working copy or the remote repository.

Checkout a Structure Nodefrom SVN

You can checkout structure nodes as directories on your local file system.

...

svn ls svn://repo/some/path/

Show Changes in Working Copy

You can use the diff command to show changes between the repository and your working copy.

svn diff | less

This will display the changes in diff format between working copy files and the repository.

You can also specify a file or dir

svn diff some/file/or/dir

Update Working Copy from Repository

You should periodically update your working copy from the repository to keep it up to date.

...

These changes will be pushed to the remote repository when you execute a commit command

Delete Files

This command can be used to delete files.

...

The deletion will occur when you commit.

When you execute the rm command, Subversion will not by default leave a local copy of the file and so will delete it immediately!

Commit Local Changes

This command is used to commit your local changes to the repository, including deletions, changes and additions.

...

This page shows the full syntax for the merge command.

 Making a Branch

Creating a development branch is done using the copy command to copy the current version of the trunk into a branches folder.

svn cp -m "Creating development branch." ^/projects/java/trunk ^/projects/java/branches/my-dev-branch

This command can also be used to make copies of files.

svn cp -m "Copying my file." myfile.java myfile_v2.java

Or to copy a file into a folder.

svn cp -m "Copying my file." myfile.java some/dir

When copying a file into a folder, the folder must already exist in the repository (or have been added using the add command).

Making a Tag

Tagging is also actually performed by using the copy command.

...

Typically, tags are not created by hand but through an automated build/release system.

Tags are only by convention in SVN as the directories are typically not made read-only.  If you are checking out and modifying something with tags in its path, you're probably doing it wrong.

Reverting Local Changes

You can replace a copy of a file in your working file copy with the repository's current version using a command like this.

...

You can also recursively revert entire directories and their sub-directories should you really want to revert a lot of changes.

svn revert -R path/to/some/dir

You will want to be careful with this, as you can easily lose your work if it is has not been committed yet and gets reverted!

Warnings and Tips

• Do not checkout an SVN project into another SVN project.  This has the potential to confuse both you and the Subversion client (and repository).
  
  
• Do not checkout and modify tags of the code.  By convention, a node representing a tag in SVN, usually with "tags" as one of the sub-directories in its path, should not be modified once it is created.  Changes should only be made on branches or the trunk.
  
  
• Be careful when using 'svn add' on a directory.  When used without file arguments, the svn add command will include all files and sub-directories.  You may not want this, so it is better to explicitly list files when adding them.
  
  
• Be careful when using 'svn add' and 'svn commit' without any arguments or with directories.  This may cause many files to be added to the repository that should not actually be tracked and will subsequently need to be removed.  Once a file is added, it is tracked "forever" by the repository and never really deleted unless the repository is rebuilt with that commit stripped out.  So please double check that you are adding only the files that are intended to be included.  Before making a large or complicated commit, first use svn status in your working copy to see what files will be committed so you can verify that the status is correct.
  
  
• Use the '--dry-run' argument before executing complex or dangerous commands.  This will show you what will happen without the command actually being executed.
  
  
• Do not be too dependent on your IDE's Subversion plugin.  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.  You should also be careful of certain GUI commands for adding files, as they will often include many files in the commit that you do not want (which is why typically it is preferable to list out all files that should be in a commit or add them individually).
  
  
• Update your working copy regularly.  This will make sure you do not cause conflicts by modifying a file that someone has already made changes to in the repository.  Also, the longer you wait between updates, the more chance that you have changes in your working copy which are not compatible with the repository's version.
  
  
• Do not develop code in your working copy for an extended period of time without committing it.  This is especially true if there is the possibility that someone else is working on the same file.  When possible, prefer checking in your work at the end of each day, or, at a minimum, the end of every week.
  
  
• Use branches when making an extensive set of complex changes to the trunk.  This will ensure that the trunk is not broken by committing unstable code, and it will also allow you to commit changes that "break everything" without affecting anyone else using the trunk.

...