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 Berkeley D B (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.

Got my MacOsX client code that supports SSH here

• there are 2 projects to build client GUI-s for the Mac

  • sven - crude alpha only seeking feedback

  • [SvnX] http://www.lachoseinteractive.net/en/community/subversion/svnx/

Haven't had much luck with [SvnX]

• the 1st time I tried it, we were doing [SVN] over SSH that's run on a non-standard port

• the 2nd time, we were using SSL, but with a self-generated key, no trusted authority, so that raised an error message.

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 Sub Version

• 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.

User Options Recent Changes Help Page