SubVersion

an in-process Open Source Version Control System

http://subversion.tigris.org/

http://subversion.tigris.org/project_status.html

Subversion is written in ANSI C and uses APR, the Apache Portable Runtime library, as a portability layer. Although the Subversion client will compile anywhere APR does, the Subversion server depends on BerkeleyDB (as well as Apache 2.X, but Apache is as portable as APR). In theory Berkeley DB is portable to most of those platforms as well (except Win95/Win98, where it's known not to work due to shared-memory segment problems). In practice, it's difficult to get the Subversion repository running on non-Unix platforms; if you succeed, we'd like to hear about it.

Trying MacOs X GUI client end-2007: [z2007-12-15-MacSvnClient]

Mac Personal SVN Server

Basic Command Line commands, dealing with repository someone already created and populated

• make folder where you want your working copy

• move into that directory in command-line

• do 'svn checkout (uri)' to get copy

• do 'svn update' to grab latest changes

• (make your changes to your working copy)

• do 'svn status' to see summary of changes you've made, and 'svn status -u' to see changes made by other people since your last update; do 'svn diff' for details

• do 'svn update' to grab/merge any changes made by others

• resolve any conflicts

  • manually edit a given conflict file, then do 'svn resolved (file)' which deletes all those version-copies around the file

    • I have found this process a bit confusing, probably because I don't read carefully enough.

    • you can work within the core-named file, which has the '<<<...===...>>>' shmutz in it, but that seems really annoying. But in the simplest cases (where the conflicts are at a rather big-chunk level) it might really be easier, where you can just practically remove those lines, and leave the merged bits there.

    • you do not want to diff the 'left' and 'right' files: the 'left' file is from before either branch made any relevant changes, so that's useless

    • what if you diff the 'right' and 'working' files? That can also work, but it boils down to lots of copying and pasting from one side to the other to merge every small change...

• do 'svn commit -m "message"' to commit

Feature-branch-oriented process

• make branch

• do your dev work

• test

• do 'svn log --stop-on-copy' to review which revision was the creation of the branch

• merge trunk back into your branch to catch any changes made since branch was made

  • Nice example of merging trunk changes back into your branch.

• do final/integration testing

• merge your branch back into trunk

• test again

• roll out

Simpler feature-branch-oriented approach?

• make branch

• do you dev work, re-merging trunk into your branch on a weekly basis (hmm, will people really do that?)

• when done with your branches changes, re-merge trunk in again, do final/integration testing

• then do 'svn merge --reintegrate'

Easy way to handle deleting a bunch of files from SubVersion

• delete them in your working copy

• run a simple line to remove those items from repository

Ouch, doing "moves" when you're using branches is bad news. The moral of this story is that until Subversion improves, be very careful about merging copies and renames from one branch to another. Jeez, has anyone even written a decent practice-document to attempt a semi-manual/human coordination process?

• I guess, if most branches aren't changing the files being moved, you could (a) propose a specific set of changes to the team, (b) wait to make sure there's no serious roadblocks, then (c) have each branch "owner" replicate the same change by hand and check it in? There's probably an even simpler process for (c) if you really do have isolated changes.