Page History

...

relative path - the relative path to a file or directory in the working copy (as opposed to a full URL)

repository root - the base URL of the repository such as svn://svn.freehep.org/hps/

head revision - the most recent global revision of the repository

^ - The "^" character can be used to specify the repository root for any command that accepts a Subversion URL.

...

In both cases, you will need to commit in order for these changes to be pushed to the repository.

Merge Merging Changes

Merging can be done in different ways, and a complete summary is beyond the scope of this tutorial.involves combining changes from one version of the repository with another.  

Two different types of merges will be covered here, though this is far from covering all the ways in which this command can be used.

Merge When working on a branch into the trunk:

svn merge ^/projects/foo/branches/v01-02-03/ ^/projects/foo/trunk

This is an advanced command so don't use it unless you know what you're doing.

Same command which just prints what would happen:

svn merge ^/projects/foo/branches/v01-02-03/ ^/projects/foo/trunk

After a merge, the changes are made to the local copy and must still be committed, using the usual commit command.

You can also use merge to undo commits (or series of commits).

, you will periodically want to merge from trunk to your branch.

cd my-hps-java-branch; svn merge ^/java/trunk

Similarly, you eventually will want to merge back into trunk from the branch once you are done with it.

cd hps-java-trunk; svn merge ^/java/branches/my-hps-java-branch

Merging can also be used to undo bad commits.

See for examplesSee for example:

http://stackoverflow.com/questions/13330011/how-to-revert-an-svn-commit

Make a branch

svn cp m "making a branch" ^/projects/foo/trunk ^/projects/foo/branches/foo-dev

Making a Tag

svn cp -m "making a tag" ^/projects/foo/trunk ^/projects/foo/tags/foo-1.2.3

Reverting Changes to Working Copy

...

This page shows the full syntax for the merge command.

 Making a Branch

Creating a development branch is done using the copy command.

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

Making a Tag

Tagging is also performed by using the copy command.

svn cp -m "Creating a tag." ^/projects/hps/java/trunk ^/projects/hps/java/tags/mytag

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

Reverting Local Changes

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

svn revert path/to/broken/local/file

You can also recursively revert entire directories and their sub-directories.

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 , local working copy of a Subversion structure node.SVN project.  This has the potential to create some serious issues when executing Subversion commands, and it will also confuse youconfuse both you and Subversion.
  
  
• Do not checkout and modify tags of the code.  By convention, a directory node representing a tag in SVN, usually with "tag" someplace in the 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 all files and subdirectories under that directory into the commit, which may not be your intended outcomeand 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 without with that commit includedstripped out.  So please double check that you are adding only the files which 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 or use the -dry-run argument with commit to check firstso 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 the your IDE for using '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.   This can be a pain to setup properly when using Eclipse, so the preferred method of keeping these tools compatible is installing the version of the connector from Eclipse that matches your existing command line client ( e.g. 1.6, 1.7 etc. 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.

...