Tutorials Multimedia in the Net

Winter Semester 2006/2007

Ogg Vorbis Encoding

Version Control

Raphael Wimmer <raphael.wimmer@medien.ifi.lmu.de>

What we will cover today

• Review Exercise 5
• Version Control Systems
• Exercise 6: 'Ogg Vorbis Recorder'

Version Control Systems

"Nobody is teaching people how to do source control."

(Eric Sink)

• You know Subversion/CVS
• You use

  svn update, commit, add

  predominantly
• We'll look at Branches, Best Practices, Distributed VCS

Basic Terms

• Repository
• Working Copy
• Revision
• Branch
• Merging

Basic Actions

• Check-out
• Block
• Commit
• Update
• Add/Remove

Branches and Tags

Branch:

• (Partial) Copy of Trunk at a given revision
• Evolving in different direction
• Usually merged into Trunk again later

Tag:

• Snapshot of a project in time.

(Both are simple tree copies in Subversion)

Common Branching Patterns

• Release branches ( /branches/1.0 )
• Feature Branches

Source: SVN Book

Conflicts / Merging

If you get a conflict, you need to do one of three things:

• Merge the conflicted text "by hand"
• Use only one of the conflicting versions.
• Run

  svn revert

  to throw away all local changes.

Once conflict is resolved:

svn resolved

.

When to Branch? (I)

• The Never-Branch system
  (Often used by nascent projects that don't yet have runnable code.)
  
  • Users commit their day-to-day work on /trunk.
  • Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.
• The Always-Branch system
  (Often used by projects that favor heavy management and supervision.)
  
  • Each user creates/works on a private branch for every coding task.
  • When coding is complete, someone (original coder, peer, or manager) reviews all private branch changes and merges them to /trunk.

(Source: svn.collab.net)

When to Branch? (II)

• The Branch-When-Needed system
  (This is the system used by the Subversion project.)
  
  • Users commit their day-to-day work on /trunk.
  • Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
  • Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
  • Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Best Practices (I): Committing

• Commit often
• Commit logical changesets
• Use commit messages for Changelog (+ = feature added, - = bug fixed, # = minor change, ...)
• Always do Update-Resolve-Commit cycle
• Don't break the tree (else{ feel_embarassed(); } )

Best Practices (II): Branches

• Use a Trunk
• Use directories for trunk, branches, tags
• Assign ownership to Trunk and Branches
• Tag each release
• Create a branch after each release
• Make bug fixes to branches only
• Make patch releases from branches only

Best Practices (III): Merging

• Split large files into smaller modules
• Track merges manually
• Preview merges (

  svn diff

  ,

  svn merge --dry-run

  )