Here's an opportunity to play with Subversion in some hands-on examples. The Subversion commands demoed here are just small examples of what Subversion can do; see Chapter 3 in the Subversion Book for full explanations of each. The Subversion client has an abstract interface for accessing a repository. Three Repository Access (RA) implementations currently exist as libraries. You can see which methods are available to your svn client like so: $ svn --version svn, version 1.0.4 (r9844) compiled May 23 2004, 14:04:22 Copyright (C) 2000-2004 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' scheme - handles 'https' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme If you don't see ra_local, it probably means that Berkeley DB (or relevant database back-end) wasn't found when compiling your client binary. To continue with these examples, you'll need to have ra_local available. Start by creating a new, empty repository using the svnadmin tool: $ svnadmin create myrepos Let's assume you have a directory someproject which contains files that you wish to place under version control: someproject/foo bar baz/ baz/gloo baz/bloo Once the repository exists, you can initially import your data into it, using the ra_local access method (invoked by using a file URL): $ svn import someproject file:///absolute/path/to/myrepos/trunk/someproject … Committed revision 1. The example above creates a new directory tree trunk/someproject in the root of the repository's filesystem, and copies all the data from someproject into it. Now check out a fresh working copy of your project. To do this, we specify a URL to the exact directory within the repository that we want. The parameter after the URL allows us to name the working copy we check out. $ svn checkout file:///absolute/path/to/myrepos/trunk/someproject wc A wc/foo A wc/bar A wc/baz A wc/baz/gloo A wc/baz/bloo Now we have a working copy in a local directory called wc, which represents the location /trunk/someproject in the repository (assuming the repository's root is file:///absolute/path/to/myrepos.) For the sake of example, let's duplicate the working copy, and pretend it belongs to someone else: $ cp -R wc wc2 From here, let's make some changes within our original working copy: $ cd wc $ echo "new text" >> bar # change bar's text $ svn propset color green foo # add a metadata property to foo $ svn delete baz # schedule baz directory for deletion $ touch newfile $ svn add newfile # schedule newfile for addition That's a lot of changes! If we were to leave and come back tomorrow, how could we remember what changes we'd made? Easy. The status command will show us all of the local modifications in our working copy: $ svn status # See what's locally modified M ./bar _M ./foo A ./newfile D ./baz D ./baz/gloo D ./baz/bloo According to this output, three items are scheduled to be (D)eleted from the repository, one item is scheduled to be (A)dded to the repository, and two items have had their contents (M)odified in some way. For more details, be sure to read about svn status in Chapter 3 of the Subversion Book. Now we decide to commit our changes, creating Revision 2 in the repository: $ svn commit -m "fixed bug #233" Sending bar Sending foo Adding newfile Deleting baz Transmitting data... Committed revision 2. The -m argument is a way of specifying a log message: that is, a specific description of your change-set sent to the repository. The log message is now attached to Revision 2. A future user might peruse repository log messages, and now will know what your Revision 2 changes were for. Finally, pretend that you are now Felix, or some other collaborator. If you go wc2 (that other working copy you made), it will need the svn update command to receive the Revision 2 changes: $ cd ../wc2 # change to the back-up working copy $ svn update # get changes from repository U ./bar _U ./foo A ./newfile D ./baz The output of the svn update command tells Felix that baz was (D)eleted from his working copy, newfile was (A)dded to his working copy, and that bar and foo had their contents (U)pdated. If for some reason bar contained some local changes made by Felix, then the server changes would be merged into bar: that is, bar would now contain both sets of changes. Whenever server changes are merged into a locally-modified file, two possible things can happen: The merge can go smoothly. That is, the two sets of changes do not overlap. In this case, svn update prints a G (``mer(G)ed''). The sets of changes overlap, and a C for (C)onflict is printed. See section ??? for information about how conflict resolution works.