[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[RFC] Tutorial Presentation

From: Christopher Ness <chris_at_nesser.org>
Date: 2004-12-28 19:00:19 CET

Hi all,

I am doing a 45 minute presentation about revision control using
Subversion. It is a very basic presentation, just to give people a
taste of subversion and what it can do.

I've attached what I plan to go over as point form notes and a dump file
from a test repository I built. The test repository may be helpful but
I did everything as my local user but with two different working copies
instead of two different users.

Please give it a quick read and I'd love to receive comments on what I
have done so far. I have not started branching and merging, as well as
vendor branches as those are more advanced topics.


Software Engineering IV,
McMaster University
PGP Public Key: http://www.nesser.org/pgp-key/
12:53:14 up 7 days, 58 min, 5 users, load average: 0.07, 0.07, 0.07 

Possible Tutorial Flow for Presentation @ CUSEC 2005
January 16, 9:00AM EST @ Carleton University, Ottawa

Christopher Ness McMaster University <chris@nesser.org>


* Try to use the full name of the subversion commands.
        ie) `svn copy` vs. `svn cp`
* Give real names to DevA and DevB to be more helpful.
        ie) DevA == Adam
            DevB == Betty
* Scope of this presentation is a basic introduction to revision
  control and Subversion.

Presentation Flow:

* Discuss Revision Control at a high level.
        - Why to save all revisions or states of a project
        - Working copy vs. repository
        - Single users vs. Multiple users
        - Time machine (stolen from the book)


* Create Repository
        - BDB vs. FSFS back ends
                - BDB older and possibly more stable
                - FSFS new development, available over network drives.
* Initial import of repository structure
        - `svn import`
        - Have branches/tags/trunk structure
* 2 Developers on screen as two terminal windows
        - Make local user accounts for "DevA" and "DevB" so log files
          show the correct users


* DevA creates "foo.c" and adds it to the repository
        - Show `svn add` but not `svn commit` yet.
        - explain that the file has been only "scheduled" for committal
          to the repository in the future.
* Explain how to use `svn [-v] status` to see changes in the working copy
        - Explain the "help" command for all `svn` sub commands and
          how it is 'self documenting'.
        - The `svn` man page points you to `svn help`
* Have DevB try to run `svn update` before DevA runs `svn commit`
        - Nothing happens, the repository has not changed.
* DevA runs `svn commit`
        - Explain the -m flag and explain the outputs of svn commit
        - Talk about the $SVN_EDITOR environment variable.
* DevB now can successfully run an `svn update` command to receive the new file.
        - Explain the outputs of `svn update` with help of `svn help update`
            A Added
            D Deleted
            U Updated
            C Conflict
            G Merged
* DevB can now run `svn log` to see what comments DevA made about the file.
        - `svn [-v] log` showing the file addition and paths changed
* DevA is in a "mixed revision" as they have committed a file but not updated
  their working copy.
        - Explain that svn does not run `svn update` after a commit command
        - This could be a lengthy operation for large repositories
        - Mixed revision working copies are often helpful!
        - `svn -v status` shows the mixed revisions
        - Explain that `svn update` works recursively from the location in
          the working copy down to the farthest leaf.
        - Always try to update as little of the repository as possible for
          the project you are working on.


* DevB modifies the printf() statement.
        - Something frivolous that should be removed later.
        - Do not commit right away, switch to DevA
* DevA adds a new line of code.
* DevB `svn commit`s her changes before DevA.
* DevA attempts to `svn commit` but the command fails.
        - Working copy is out of date and SVN will not allow you to override
          with an old version.
        - Error message == ""
        - DevA needs to run an `svn update` command to merge in the new changes
          to his working copy.
* Since the changes do not "conflict" with each other the merge is successful.
* As DevA, inspect the log and the diff of what was changed between revisions
        - `svn diff -r2:3` -> What changed in r2 -> r3 (new code added)
        - `svn diff -r3:2` -> What changed in r3 -> r2 (new code removed)
        - The reverse diff will roll back the changes!
* `svn diff` without arguments shows local changes in the working copy.
        - ie) The new line DevA added and tried to commit.


* DevA doesn't like DevB's changes and wants to roll back. A choice to be made:
        - Commit your local working copies changes, then roll back.
        - roll back and then commit all of the changes.
* I suggest you commit your working copies changes first, then roll back.
        - This way your changes which may have nothing to do with the roll back
          code are in a separate revision. They are not tied together if
          DevB decides to roll forward his changes again!
* DevA does `svn commit` to save their local modifications to the repository.
* DevA does a `svn merge -r3:2 ./foo.c`
        - Now inspect and test the code to see if it is "correct".
        - Not trivial for large projects.
        - You should see DevB's changes reverted back to the original
          revision in r2 along with the line added by yourself in r4.
* These changes are only in DevA's working copy. If he is not happy with
  the changes he can update the file manually, or `svn revert` to the
  previous version (stored locally) but equal to the file stored on the
  repository server.
        - Do not run `svn revert` if you have local changes in the working
          copy. You will _LOSE_ those local changes.
        - This is why we committed our changes first.
* DevA is happy with the merge and decides to `svn commit` the changes to
  roll back DevB's changes in revision 3.
        - When rolling back a change, or merging a change set between branches
          always be descriptive about what it is you are doing an include
          revision numbers!


* DevB decides to add some keywords to the source file which are expanded
  on checkout to fill in the values.
        - Add the keywords to the file:
 * $LastChangedDate$
 * $LastChangedRevision$
 * $LastChangedBy$
 * $HeadURL$

        - Now set the properties on the file using this command.
  `svn propset svn:keywords "LastChangedDate LastChangedRevision LastChangedBy HeadURL" foo.c`
* `svn status` shows two M's. One is for a modified file, the other is
  for modified properties.
* Commit both the properties and the changes to the file to store these
  changes on the server for all to see!


put stuff here.... Need to come up with some good "use cases".

Explain that the users need to be knowledgeable about branching
and merging. Otherwise simply work on the trunk unless it is
very disruptive.

svn command line (win32, Unix)
TortoiseSVN (win32)
XCode (Apple)

See this page for more plugins, bindings and projects:


The SVN Book (aka, "the book") can be found online free in many different
formats for your reference at this URL:


The latest updates are in the subversion self hosted repository found at:

The latest revision of the SVN repository as of my writing this file on
Tue Dec 28 12:16:26 EST 2004 is r12507

Chapter 5 was updated 3 days ago to warn against modifying transactions
in a hook script.

Received on Tue Dec 28 19:02:55 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.