bradchoate.com

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