Tag Archives: svn

Version control practices

Thoughts on good practice when using version control, based on my experience, and not in any particular order.

Commit one “thing” at a time, where “thing” is a feature or a bug fix. Don’t commit a feature at the same time as a bug fix, or multiple bug fixes at once.

Review what you’re actually committing – the files, and their contents. You may have temporary changes to some files, you might have forgotten to deal with a FIXME, you might have used an editor that’s messed up the whitespace/indentation of entire files.

Sometimes you get called upon to fix something while you’re working on a feature, with some half-done changes in your working copy. Create a branch, switch to it, commit your half-done stuff, then switch back to trunk to fix whatever it is. When you’re done fixing, either continue your work on the branch or just merge it in to trunk straight away and carry on.

Commit messages should say what you did, and if relevant, why (e.g. what issue it fixes). Bad examples are “changed js file”, “fix bug”. If you’re working on a feature and make multiple commits, “<name of feature>” is not a good message.

Learn how to resolve conflicts properly, take care when doing it, and test after merging (even if there were no conflicts). If in doubt about a conflict, ask someone. Learn how to resolve tree conflicts properly. Use a clean working copy for merges.

Learn how to revert committed changes (reverse merge), or ressurect files with history (svn copy).

Preserve history on file moves. Use svn move, or your SVN-enabled IDE to move files. These will track the fact that the file was moved, and the history will remain linked in SVN – this is called “addition with history”. If you just use Windows Explorer, your move will become just a delete and a corresponding unrelated add.

Version Control with Subversion

I recently read the book Version Control with Subversion free online book. I’d recommend it to anyone who uses SVN as part of their work, including GUI client users.

If you’re a developer, you can probably skip the sections on repository administration (I did). It’s good to skim them though, so you’re aware of server side capabilities that you might want to ask for such as hook scripts and write-through mirroring.

Some points I picked up/thought people would generally benefit from knowing:

1. Fundamental Concepts

  • 1.7 has a new working copy format with only one .svn folder, in the root of the working copy.
  • 1.7 prevents use of mixed revision working copy as target of merge, to prevent common problems.

2. Basic Usage

  • Repository layout considerations – have trunk/branches above all projects, or underneath each one
  • svn status -u option shows * if someone modified the item in the repository. If also locally modified, will have to update before committing.
  • dc option for interactive conflict resolution diffs only the conflicted part.
  • svn resolved is deprecated in favour of svn resolve –accept working.
  • svn commit -F option reads message from file.
  • svn maintains private to-do list to help recover from e.g. killed processes. This is what svn cleanup uses.
  • Resolve tree conflict – diff the old file, edit the headers to point to new path, apply patch. Then delete old file with force, and resolve –accept working the new one.

3. Advanced Topics

  • svn log -r base:head – see what’s happened since last updated.
  • Pegged revisions avoid ambiguity when dealing with deleted or renamed moved files. @rev at end of path. Defaults to base.
  • svn:eol-style property can be useful when dealing with multiple platforms.
  • Use svn add –force instead of svn add *, as the latter is expanded by the shell and might include ignored files.
  • Keyword substitution in files using $var$, need to set svn:keywords property on the file.
  • Sparse checkout – can check out immediates, exclude unwanted folders, then telescope what’s left. Can also de-telescope.
  • svn:needs-lock property will make file read-only on file system.
  • svn:externals – auto checks out what’s referred to.
    • consider specifying revisions, so when you backdate your copy you get the old version of the external as well.
  • Changelists – file can only be on one at once, folders not supported. Lists are removed when committed, but option to keep them.

4. Branching and Merging

  • A branch is “dead” after reintegration
    • To keep it alive, need to do a record-only merge of the reintegration revision from trunk to the branch, to prevent it being subsequently merged to the branch.
  • Undo changes by reverse merge. To revert 303, do -r 303:302 or -c -303. Doesn’t record mergeinfo.
  • Use svn copy to ressurect files with history (A+ status).
  • When merging after cherrypicking, will do separate ranges to skip the cherrypicked one(s). Any in-between conflicts must be resolved interactively.
  • svn merge is simply “diff and apply”. No magic.
  • General use of record-only merge is to block changes from being merged somewhere, by lying that they’ve already been merged there.
  • Move is just a copy and delete. Dangerous when merging moves and renames – comes up as a deletion and an add, you won’t notice that your changes to the renamed file have been lost.

5. Repository Administration

  • Various useful hooks, not just pre-commit.
  • Use svn relocate if server name changes. Admin can set up a redirect, and 1.7 clients will auto-relocate.
  • Can use hooks to prevent commits to tags.
  • When branching for a release, manually port bug fixes in both directions.
  • Use vendor branches when we make customisations to third party code.

7. Customizing Your Subversion Experience

  • Global config to preserve extensions on conflict files, so they open in the default editor.
  • File timestamps are normally those of last touch, can config to make checkout use last commit time.
  • Various methods of setting which editor to use e.g. for conflict resolution (one is SVN_EDITOR environment variable).
  • svnversion command summarise local revisions of working copy – easy way of determining if it’s mixed revision or not.

9. Subversion Complete Reference

  • -x options for diff and blame, for ignoring whitespace
  • svn info can be applied to folders, files and urls
  • svn mergeinfo command, with show-revs merged or eligible options
  • Status R (replaced) means item was scheduled for deletion and then one with the same name was scheduled for addition.