OSCON: Subversion Best Practices

Here’s a summary of an OSCON session I’m attending right now. Every seat in this room is full.

This talk is done by Ben Collins-Sussman & Brian W. Fitzpatrick (Google employees).

  • Server best practices
    • Which server to use? Depends.
      • svnserve: Fast, light, quick. Good for simple setups. svn+ssh if you need encryption.
      • Apache: Mount as a network share; flexible authentication; browsing of repository; logging.
    • One repository or many? Depends.
      • One, when: shared users, shared code; reduce maintenance burden (ASF uses a single repository for their entire directory of projects).
      • Many, when: radically different access policies or data types (ie, text store versus binary store).
    • Authorization policy
      • svn 1.3 supports path-based authorization.
      • Use no authorization if possible (open-source context).
      • Encourage a culture of trust.
      • Remember, you can’t really delete anything.
    • Repository browsing tools
      • Should you set one up? The Apache server comes with a free browser. Doesn’t support diffs, or selecting specific revisions. Annotations, etc.
      • Hardcore users will use the svn commands.
      • Ones they like: ViewVC, Trac
    • Hook scripts
      • Pre-commit hooks
        • Don’t attempt to modify the transaction. Instead, send an error and block the transaction.
        • Hooks we like:
          • check-case-insensitive.py (checks to prevent against checkins that would create conflicts with other files that might differ in case alone)
      • Post commit hooks
        • Run them in the background &
        • Hooks we like:
          • mailer.py (email notification of commits)
          • CIA bot (IRC channel notification of commits)
    • Locking/Reserved Checkouts
      • You have the ability to not be concurrent. When would you do this?
      • Binary file modifications; or other files that can’t be merged. You’d want to lock such files to prevent conflicts.
      • Property svn:needs-lock accomodates this. It checks out the file as read-only, and becomes read/write once you lock it for modifications. If you try to lock and can’t, it’s because someone else is working on the file.
    • Autoversioning
      • Only for Apache server
      • Good for non-coding projects
      • Good for non-techies
      • Bad for traditional coding projects
        • no log messages
        • potential email spam for unauthorized repos.
        • empty revisions
      • Good for tricking people into using version control. :)
    • Repository maintenance
      • Backup: dump versus hotcopy
        • When you dump, it checks out every single revision in the repository.
        • hotcopy is a file copy of your repository database.
      • History obliteration should be avoided
        • Takes a long time
        • Invalidates working copies
        • Why? Someone did something stupid, like checked in a list of passwords, government secrets, etc.
        • svndumpfilter has limitations
        • If you must obliterate, try selectively dumping
      • hotcopy versus rsync: Use hotcopy to make the backup to preserve consistency, then use rsync on that.
    • Encourage Code Review
      • Commit often
      • Commit in small, discrete chunks
      • Use consistent log messages
      • Send commit emails to team
      • For example: fix a bug, commit, fix a bug, commit.
    • Branches
      • Don’t fear them!
      • Use types of branches
        • Short-lived task branch
        • Medium-lived feature branch
        • Long-lived release branch
      • Have a release policy
    • Merge Tracking
      • Needs to be managed by humans
      • Describe merges in log messages (editor: we include the actual “svn merge” command that was used)
      • svnmerge.py
      • Subversion 1.5: real merge tracking!
        • no, really.
        • available in the Subversion trunk.
        • May be available in 6 months or so.
    • Standardize on one locale
      • All filenames and log messages are stored in UTF-8 on the server.
      • Choose one locale and stick with it… or else.
    • Use Autoprops
      • No, the server can’t transmit them to clients. Maybe in the future.
      • Useful autoprops:
        • svn:mime-type
        • svn:eol-style
        • svn:needs-lock
  • Cool Client Tricks
    • Switching to a branch in mid-flight
    • In-place “import”
      $ cd dataset/
      $ svn mkdir URL
      $ svn checkout URL .
      $ svn add *
      $ svn commit
    • Mixing and Matching Components
      • svn:externals
      • svn switch on empty directories
    • Managing a website in Subversion
      • serve site from a working copy
      • disable httpd access to .svn/
      • write post-commit hooks to update working copy
    • Use svnversion
      • $Revision$ doesn’t do what you think
      • This command yields the revision of the working copy.
    • Use a template
      • Dealing with a “mostly standardized file”:
        • Commit a template of file to repository
        • Have build system copy it to unversioned file
        • Users edit unversioned file


TrackBack URL for this entry:


This article was published on July 27, 2006 10:54 AM.

The article previously posted was Worst Toenail Ad Ever.

The next article is OSCON: Extreme Perl Makeover.

Many more can be found on the home page or by looking through the archives.

Powered by Movable Type