Wiki Home

Sub Version


Namespace: Wiki
A source code version control system available at http://subversion.tigris.org. Free as is freedom as well as free as in free beer. Works securely over the internet by integrating with Ssh or Apache. Scales well. Addresses shortcomings of Cv S by cleanly supporting file and directory renaming and moving, atomic transactions of multiple files and much more. Clients available for all major platforms. Free book available from http://svnbook.red-bean.com/, printed version from O'Reilly and Associates. Another book available from the Pragmatic group t http://www.pragmaticprogrammer.com/titles/svn/, ISBN 0974514063. -- tr
Setup Steps:

Initial server setup
Install the server software.
Create a dir to hold Sources: /home/carl/subversion/sources

Start the server (better put this in the boxes startup script)
$ svnserve --foreground -d -r /home/carl/subversion/sources/


Initial Client Setup
Install the client software. (there is one official client, and currently 4 spinoffs, one being Tortoise SVN)
[general]
global-ignores=*.zip *.bak *.exe *.err *.ZIP *.BAK *.EXE *.ERR

For each Project
Server:
Create the repository: $ svnadmin create /home/carl/subversion/sources/theproject
Edit the config: $ vi theproject/conf/svnserve.conf

[general]
anon-access = read
auth-access = write
password-db = passwd


create a password file: $ vi theproject/conf/passwd
[users]
fred = abc
barney = def

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 def
CarlK: 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 pain
http://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.

Other Client
Get current project
D:\vfe\dev\>svn checkout svn://dev.personnelware.com/theproject --username barney --password def
creates d:\vfe\dev\theproject\

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.


Carl Karsten

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

Vladimir Berezniker

There are also VSS Explorer like tools available. Tigris themselves provide a desktop tool named RapidSVN at their site at http://rapidsvn.tigris.org. Another one is WorkBench that looks more common than RapidSVN.

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

JoKi
See also: Subversion Testing
Category Source Code Control, Category Configuration Management
( Topic last updated: 2008.07.28 07:01:03 AM )