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.
Thanks,
Chris
--
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
http://www.fsf.org/philosophy/no-word-attachments.html
Possible Tutorial Flow for Presentation @ CUSEC 2005
January 16, 9:00AM EST @ Carleton University, Ottawa
Christopher Ness McMaster University <chris@nesser.org>
Conventions:
============
* 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)
CREATING THE REPOSITORY:
=======================
* 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
ADDING FILES AND COMMITTING:
===========================
* 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.
TWO USERS MODIFYING THE SAME FILE:
=================================
* 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.
ROLLING BACK A CHANGE:
=====================
* 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!
SVN PROPERTIES (KEYWORDS):
=========================
* 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!
SVN BRANCHING AND MERGING:
=========================
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.
PLUGINS:
=======
svn command line (win32, Unix)
TortoiseSVN (win32)
XCode (Apple)
Subclipse
See this page for more plugins, bindings and projects:
http://subversion.tigris.org/project_links.html
MORE READING:
============
The SVN Book (aka, "the book") can be found online free in many different
formats for your reference at this URL:
http://svnbook.red-bean.com/
The latest updates are in the subversion self hosted repository found at:
http://svn.collab.net/viewcvs/svn/trunk/doc/book/book/
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