Introduction to Subversion (SVN) and Google Project Hosting

1. Introduction to Subversion (SVN)and Google Project Hosting Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu HI 96822

2. Basic concepts • SVN uses a centralized repository. • We will not cover repository administration. • Clients connect to a repository to download working copies. • Working copies: • Ordinary directory trees. • Contains your files plus administrative files in special subdirectories named '.svn'.

3. Updates, Commits, Revisions • Working copy: • A local directory tree • Commit: • Upload your working copy to the SVN server. • Creates a new repository-wide "revision", or snapshot of the state of the repository. • Update: • Make some or all of your working copy consistent with a given revision. • You can update to the • latest revision • any prior revision

4. Review: Versions/Configurations for RCS/CVS style CM • Each file has its own version number. Foo.java (1.1) Foo.java (1.2) Foo.java (1.3) Foo.java (1.4) Foo.java (1.5) Foo.java (1.2.2) Foo.java (1.2.1) Bar.java (1.1) Bar.java (1.2) Bar.java (1.3) 1.0.0 1.0.1 1.1.0

5. SVN has repository-wide revisions • Each time you commit, you 'stamp' not the files you commit with a new version, but the entire repository. File changes color to indicate changed contents, but Subversion doesn’t maintain a file-based “version number”. Foo.java Foo.java Foo.java Foo.java Foo.java Bar.java Bar.java Bar.java Bar.java Bar.java r1 r2 r3 r4 r5

6. "Copying" in SVN is cheap • The database backend in SVN means that you can make "copies" of an SVN directory structure very cheaply. • No files are physically copied, just pointers to the files and info on which revision. • This means that you create branches, tags, and the "trunk" by creating and merging directories that each contain an entire "copy" of an arbitrary number of files.

7. Trunk, Branches, Tags • SVN project directories are structured by convention with three top-level directories: • trunk/ • Represents the 'main line' of development with an entire copy of the project. • branches/ • Contains subdirectories, each holding an entire copy of the project. • Each branch constitutes a significant enhancement to the project that can be worked on independently. • tags/ • Contains subdirectories, each containing one snapshot of the project. • Each snapshot represents a "public release" or other archival configuration of the project.

8. Example • <repository>/stack/ trunk/ build.xml src/ : tags/ release-1.0/ build.xml src/ : branches/ add-generics/ build.xml src/ : add-intstack/ build.xml src/ :

9. Trunk vs. Branch • Trunk represents "gold" version of system • Should always compile, always pass tests. • In this class, it means passing the “verify” target! • Branches represent "temporary" development streams to implement significant new features. • Allow commits to repository without breaking the "gold" version in the trunk. • Branches don't need to always compile, pass tests. • You must "merge" a branch back into the trunk when completed. • Or at intermediate points when branch is "stable". • The longer you wait to merge, the more difficult the merge might be.

10. Our SVN server: Google • Google provides a free service for hosting open source projects. Includes: • SVN server • Mailing lists • Issue tracker • We will use Google Project Hosting this semester for all class projects. • Also good choice for hosting your future open source projects! • Alternatives: SourceForge, GitHub

11. Local SVN Client Choices • Upcoming examples of local workspace manipulation use TortoiseSVN client program. • Best choice for Windows. • Other clients exist for other platforms • http://subversion.tigris.org/links.html • For Mac I use: • SmartSVN

12. Google Project Hosting • Home: http://code.google.com/hosting/ • Docs: http://code.google.com/hosting/faq.html

13. Basic Use Cases • A. Project source download • B. Basic workflow • D. Defining a new Project

14. Project Download • Preconditions: • Obtain the URL for the project. • If commit access is desired: • Obtain membership in project • Get your SVN password • SVN 'checkout' the 'trunk' to your local computer • Use ‘http’ URL for anonymous, read-only • Use ‘https’ URL for commit access.

15. Project Workflow • 1. Update: • "SVN Update" to make your local workspace consistent with latest version from repository. • 2. Run "verify" target • Make sure your updated local version is running correctly. • 3. Edit: • Make improvements to the Project files. • 4. Run "verify" target • Make sure system works correctly before committing! • 3. Commit: • "SVN Commit" to 'publish' your improvements to the repository.

16. Creating a new project • 1. Define the new project with Google Project Hosting. • Add initial members. • Set up discussion list in google groups. • Get your SVN password. • 2. Populate the SVN repository • Checkout the 'trunk' directory to a newly created local directory. • Add project files/directories to that directory. • SVN 'add' those files. • SVN 'commit' those files.

17. E. Beyond basic usage • SVN has many other useful features: • Using branches to isolate development • Most complex part of SVN usage. • SVN Blame • Show who committed last version of each line in the file. • SVN Switch • Move between trunk, branches, tags. • These will be covered later as need arises.