You've been to the Subversion tutorial session, or maybe you're already using
Subversion. Enough of the basics. Instead of learning the mechanics of usage,
come learn about best practices for deploying Subversion as a central tool in
your open source project.

- Should you have one big repository or many small ones?
- How should you lay out your repository?
- What should your branching and release policies be?
- Who should be able to commit where?
- What should log messages look like?
- How should your team configure commit emails?
- How should you deal with file-locking and backups?

These questions and others will be discussed in detail.


* Intro
  - who are we?
  - what gives us the right to espouse these opinions?
  - not an svn tutorial -- why do this talk?
  - What we're going to tell you

* Server Best Practices
  - which server is best in which situations?  Googlefight!
    - must comply with your hosting service (http?  ssh?)
    - svnserve *is* faster, lighter, and more suitable for less complex setups
    - Apache HTTP Server has more points of integration (plus straight web-browsing of repos)
      - httpd nicenesses:
        - mod_dontdothat
        - custom logging
  - one repos or many?
    - We think it should be one 99% of the time
  - what authorization policy to use?
    - try to encourage culture of trust:  try not to do path-based authz within a project
    - remember, you can't *actually* delete something from Subversion)
  - when to use ViewVC (or equivalent)?
  - recommended hook scripts:
    - pre-commit scripts:  check-case-insensitive.py
    - post-commit scripts:  mailer.py, CIA bot
  - when to use locking?
    - do NOT emulate sourcesafeN
    - use only on non-mergeable files, preferably high-traffic only
    - use svn:needs-lock if there are non-techies involved
  - when to use autoversioning?
    - 2 types of projects:  techies writing code, non-techies sharing binary docs
    - don't mix these two worlds!  else you get email spam, revision spam, no log messages.
  - repos maintenance
    - backup techniques:  when to use dump vs. hotcopy
    - removing parts of history
      - avoid it if possible:  takes long time, and invalidates working copies
      - svndumpfilter and its shortcomings
      - selectively dump (if removing the last revision(s))

* Client Best Practices
  - encourage code review
    - use commit mailer
    - commit early & often
    - commit in discrete chunks
    - have consistent log messages
  - Branches
    - Don't be afraid of them!
    - when to use branches?
      - task branch
      - feature branch
      - release branch
      - branching & release policies
  - techniques for tracking merges
    - Manually (document what you've done in log messages)
    - svnmerge.py
  - standardize on one locale (charset encodings)
  - autoprops for eol-style, mime-type, needs-lock
  - Client tricks
    - import without re-checkout! ("in-place import")
    - switching to a branch
    - have a password caching policy

* Common Use-Cases
  - mixing & matching components (the 'p4 client' workarounds)
    - svn:externals
    - 'svn switch' on empty dirs
  - managing a website in svn

* End
  - What we told you
  - QA