10.svn - ics-software-engineering
Download
Report
Transcript 10.svn - ics-software-engineering
Introduction to
Subversion (SVN)
and
Google Project Hosting
Philip Johnson
Collaborative Software Development Laboratory
Information and Computer Sciences
University of Hawaii
Honolulu HI 96822
(1)
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'.
(2)
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
(3)
Review: Versions/Configurations for
RCS/CVS style CM
Foo.java
(1.1)
Foo.java
(1.2)
Foo.java
(1.3)
Foo.java
(1.2.1)
Bar.java
(1.1)
1.0.0
Foo.java
(1.4)
Foo.java
(1.2.2)
Bar.java
(1.2)
1.0.1
Each file has its own version number.
(4)
Foo.java
(1.5)
Bar.java
(1.3)
1.1.0
SVN has repository-wide revisions
Each time you commit, you 'stamp' not the files you commit
with a new version, but the entire repository.
Foo.java
Foo.java
Bar.java
Bar.java
r1
Foo.java
Foo.java
Bar.java
Bar.java
r2
Foo.java
r3
Bar.java
r4
r5
File changes color to indicate changed contents, but
Subversion doesn’t maintain a file-based “version number”.
(5)
"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.
(6)
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.
(7)
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/
:
(8)
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.
(9)
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
(10)
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
(11)
Google Project Hosting
Home: http://code.google.com/hosting/
Docs: http://code.google.com/hosting/faq.html
(12)
Basic Use Cases
A. Project source download
B. Basic workflow
D. Defining a new Project
(13)
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.
(14)
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.
(15)
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.
(16)
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.
(17)
(18)