Development with Subversion

...

This is an example of listing contents of a relative path.

svn ls trunk/parent

...

svn ls svn://svn.freehep.org/hps/java/trunk

Synchronizing your copy with the remote repository

...

This is an example of making a branch. 

svn cp -m "Making a new HPS Java branch for some reason." ^/projects/hps/java/trunk ^/projects/hps/java/branches/hps-java_HPSJAVA-123

Note here that we have included The name of the branch is 'HPSJAVA-123' in the name as a to reference to a relevant JIRA item.   (This  This is just a dummy name.  In actuality, it should be a real JIRA item. )  This  This allows someone to understand the purpose of that branch from its name.

Performing a merge

...

Using the above example branch, the following is the equivalent merge operation.

svn merge ^/projects/hps/java/branches/hps-java_HPSJAVA-123/ ^/projects/hps/java/trunk

...

In general, unless very minor changes were made to the code on the branch, you should always communicate with the other developers about plans for merging and what the state of the trunk will be after the merge is performed.
 

After a merge, the changes (additions, deletions, etc.) are only made to the local copy and must still be committed, using the usual commit command.

...

For instance, this command will revert a single local file to its master copy, removing any changes you have made on it locally.

svn revert sandbox/castles.txt

...

The command will execute immediately unlike an addition or deletion. 

You can also revert entire nodes recursively, which will replace all changes in and under that node with the master copy. 

svn revert sandbox --recursive

...

You should be careful when reverting entire nodes, as this will completely clobber any changes you have made. 

Using revert results in changes to your local copy that are not recoverable e.g. all your local edits will be removed.  So be careful when using this command. 

Miscellaneous Tips and Warnings

• Do not checkout SVN URLs into some other project that is already managed by Subversion.  This has the potential to create some serious issues when executing Subversion commands, and it will also confuse you. 
   
• Do not modify files that are in tags of the code.  All changes should be made on branches or the trunk.  Tags should be considered 'frozen' once made. 
   
• Be careful when using svn add on a directory, as by default it will add ALL files and subdirectories under that directory, which may not be your intended outcome.  (see next item) 
   
• Be careful when using svn add and svn commit without any arguments or with directories, 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 actually be tracked and will subsequently need to be removed.  Once a file is added, it is tracked "forever" by the repository and cannot be easily deleted, even though it might then be removed in the trunk and subsequent revisions.  So please double check that you are adding only the files which are intended.  Before making a large or complicated commit, first use svn status in your working copy to see what files will be committed or run svn --dry-run commit. 
   
• When doing complex tasks like merging, use the --dry-run argument like svn --dry-run merge to see what will happen without the command actually being executed. 
   
• Do not be overly dependent on your IDE for executing Subversion commands.  Always make sure to have a compatible SVN command line client available. 
   
• At the beginning of the work day, you should generally do a quick svn up on any modules you will be working on in order to synchronize the working copy with the repository.  This will make sure you do not cause conflicts by modifying a file that someone has already made conflicting changes to in the repository. 
   
• Do not develop code in your working copy for an extended period of time without committing it, provided of course 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.  When possible, prefer checking in your work at the end of each day, or, at a minimum, the end of every week. 
   
• If there are files that are always generated by your project's build which should not be put into version control, consider adding these file names to the ignore list for the project's directory, as covered here: 
  http://stackoverflow.com/questions/86049/how-do-i-ignore-files-in-subversion

...