Starting Client:
Add a project to the repository:
D:\vfe\dev>svn import theproject svn://dev.personnelware.com/theproject --message "Initial Checkin" --username fred --password abc
and make this a working copy
D:\vfe\dev\>svn checkout svn://dev.personnelware.com/theproject --username barney --password defCarlK: is there a good reason why "import" doesn't do a "checkout" ?sussman: CarlK: only because we were imitating cvs.
sussman: CarlK: see the 'in-place-import' FAQ
sussman: CarlK: it will ease your painhttp://subversion.tigris.org/faq.html#in-place-import
easier way?: skip the import step - svn co - it will add the metadata to the existing dir. svn add * to add the existing files/dirs to the WC. svn ci to commit them.

All clients:
After work is done on existing files:
D:\vfe\dev\>svn commit -m "fixed bug #123"

Adding more files
D:\vfe\dev\theproject>svn add data\sbt\
(note, this just gets them under control, but does not 'commit' them to ther server.)
I have been using it for the last month and love it. If anyone isn't using anything, then they should start using this. I have used Visual Source Safe in the past and I find Sub Version easier to work with.

The bigest problem I have with it is the ramifactions of it being a cross platform tool (Windows, Mac, Unix, etc.) which means it supports case sensitive file systems. Windows is insensitive (foo.txt will be replaced if you create FOO.txt) and VFP has a nasy habit of changing the case (not sure when, but foo.prg sudenly becomes foo.PRG) which causes Sub Version to think a new file has shown up. I am still not 100% sure of the mechanics of what happens next, but I do know it causes problems. There is a server side hook that will keep the problem on the client, so you have to resolve it before commiting the updates.

Another thing that some people see as a problem is the lack of "locking" or "checkout" which is really just a project management problem: 2 developers should not be working on the same file at the same time. This wouldn't be as big of a problem if VFP didn't put more than one class in a file (vcx), and if multiple changes to metadata (like dbcx tables) could somehow be merged. They can, but noone has written the code yet. To help with the class problem, I am working on Vcx Diff.

I have found that although the software works fine, the uesr (me) has problems using it. Mainly I foget to add new files that I create. Also I don't check in my changes as often as I should.

I am thinking a VFP project hook class might solve the lazy user problem. It would also give me the chance to use Vcx Diff to show what changed between versions.

(albeit in response to an ancient comment) I personally don't see two people working on the same file as people problem, but rather a technical one. Large projects where the source is all in text, and a few additional resources in binary format, tend to cope with conflicts rather well if developers are changing different parts of a file, mainly because subversion will flag up the fact that you have a conflict when you try to commit. Clever development tools will try and resolve the conflicts (working along the lines of diff3) if they are in unconnected locations. Problems only arise where your modifiable source is in a binary format, such as VFP's forms and controls, since binaries lack the concept of a "line", there is no way to accurately diff them.
There is also a very nice windows GUI that integrates with windows explorer called Tortoise SVN and available at http://tortoisesvn.tigris.org. Project also has excellent documentation describing server setup and daily use scenarios.

I'm using Sub Version on a Windows Server 2003 system as main repository for more than a year. Instead of the built-in svn server I configured Apache HTTPd to act as web server. It's quite easy while using mod_dav_svn - an extension to Web DAV in combination with Sub Version. Very nice...