== Introduction to Subversion (Svn) ==

Subversion (Svn) is a tool for managing software development that keeps track of who modified what and allows returning to a previous version if changes don't do what was expected.  All the files are stored on hosted-projects in a repository named roms_sed. Users pull the most recent version to their local machines with a Svn client, use the code, making modifications as needed, then may push their changes back (again using the client) to the repository on hosted-projects.

Below is a general description of how subversion works.  Please look at the [http://svnbook.red-bean.com Svn book] for more detailed information.  Brief instructions for using two GUI clients (one for PC and one for Linux) we've tried are included.

'''Conceptual model'''

 * A svn server holds one or more code repositories
 * A repository consists of all versions of the program/document under development, plus info on who made changes, and when.
 * A svn client may access files in the repository using Svn client software
 * Each each change to the repository the revision number to be incremented by 1.
    * if file_a is changed, then file_b, then file_a, then file_c, then file_b, at the end, the repository is a revision 5.
    * the revision history of file_a has 1,3; file_b has 2,5 and file_c has 4
    * revisions in a repository are sequential, but the revision history of individual files may skip some numbers.
 * The repository referred to below contains the ROMS Sediment Transport model code: 
 {{{
     http://svn1.hosted-projects.com/cmgsoft/roms_sed
}}}

'''Using Subversion'''

To enable use of subversion, client software must be installed on the local machine. Most Linuxes come with subversion (the command name is svn), so shell commands may be used without installing additional software.  The general form of subversion commands is:
 * {{{   svn action from to {optional_qualifiers}}}}
To check-out the files from the ROMS_SED repository, enter:
 * {{{   svn checkout http://svn1.hosted-projects.com/cmgsoft/roms_sed /home/mydir/code/roms_sed}}}

You only check out once, after that, a hidden directory called .svn exists to keep track of the source, destination and a bunch of other information.  So to commit your changes back to the repository, cd into a local dir under subversion control (/home/mydir/code/roms_sed or below) and enter: {{{svn commit}}}.  For more detail on command line use and syntax, see the [http://svnbook.red-bean.com svn book].

Several GUI front-ends to subversion exist, allowing the user can have visual prompts to help them manage their files. Two free GUI clients we've tried are described in the links below:


'''[wiki:TortoiseHelp Help on using TortoiseSVN, a GUI (subversion) client for PC]'''

'''[wiki:SmartsvnHelp Help on using SmartSVN a java based multi-platform GUI (subversion) client]'''

----

'''Important Subversion Terms'''

   * '''''Checkout''' = download a NEW project from the repository (do this once)''
   * '''''Update''' = get the most recent changes to a project from the repository (only possible after intial checkout)''
   * '''''Commit''' = send your changes to the project repository''

'''Access'''

 * Anyone should be able to view the contents of the repository, look at this wiki and view the tickets.
 * A username and password are required to put your changes back into the repository. 
 * To work with data from a repository, you "checkout" a version. 
 * You can check out the most recent version or a specific release, and either the entire repository, or just certain subdirectories. 
 * Checking a project out makes a copy of the most recent version on the client requesting checkout
 * Svn suggests only checking out into an empty directory

'''What you get'''

 * If you choose to checkout the project into my_roms_sed, you’ll find trunk, branches, and tags directories created in your local directory.
 * Trunk is the main area for development, and unless otherwise instructed, work with the code in trunk
 * Tags will contain stable versions if they exist
 * Branches will have offshoots implementing new functionality- develop in the branch, then merge back into the trunk
 
'''Work flow'''

 * Start each session with update: 
 * Modify and debug the code locally
 * When you’re done with changes, commit changes to the repository 
 * This will cause the version number to be updated at the repository
 * repeat

'''Conflict resolution'''

 * Svn uses copy, modify, merge as it’s operational model
 * It is possible for two people to change the same chunk of code at similar times, and when the commit happens, this will be detected, and the users will have to interact to resolve the conflicts
 * A process similar to diff finds the conflicts
 *  Right click !TortoiseSvn, and try merge and/or blame to deal with conflicts

'''Notes'''

 * Everything happens at the folder level- Svn doesn’t operate on single files.
 * Use svn tools to copy files into or our of a svn directory so the change can be tracked- the change will propagate to the repository on the next commit
 * The .svn directory in each project main directory keeps track of the repository information, so you don’t have to say where to put commits, it puts them where it got them.


[wiki:WikiStart return] to the roms_sed start page