Re: request for input: possible move to SVN

Thank you very much for such a detailed account of your experience!

My current svn repositories don't get wedged any longer because I
access them exclusively via mod_svn, no local access (including no
ViewCVS).  I want to test the "fsfs" backend of svn 1.1, which has no
berkeley db backend to get wedged.

Performance-wise, subversion may not be as fast as some commercial
products, but it beats the pants off of CVS.

BTW, I'm heartened by the <!-- cache expires at blah --> comments in
the source of arenaunlimited.com!

js

On Thu, Oct 28, 2004 at 06:40:47PM -0700, Matthew Bogosian wrote:
> On Oct 27, 2004, at 20:56, Jacob Smullyan:
> 
> >I have been using subversion for my own projects lately, and much
> >prefer it to CVS.  In particular, the ease with which files can be
> >moved and branches maintained, as well as the noticeable performance
> >improvements, make it to my mind a clear win.
> >
> >...
> >
> >What do you think?
> 
> I am not a developer on the SkunkWeb project, but I have to concur with  
> Jacob's assessment of Subversion. We've used it for two major projects  
> and found it to be an acceptable alternative to many revision control  
> systems (and vastly superior to CVS).
> 
> For us, there were two areas of major concern when switching from our  
> expensive commercial solution (which will remain unnamed). The first  
> was performance in a medium-sized project (eight developers). The  
> second was data integrity. Being that Subversion was relatively new  
> (and Berkeley DBs -- the underlying data storage mechanism for  
> Subversion repositories -- are relatively fragile), we were tentative  
> to try it for a new project.
> 
> It turns out our fears were somewhat justified. We chose to access our  
> subversion repositories via mod_svn and Apache 2.0. Although the  
> web-browsing aspect was kind of sexy, performance seemed much slower  
> compared to what we were used to with our other revision control  
> system. Second, the repository frequently became "wedged" and we needed  
> to halt Apache and issue "svnadmin recover" commands to recover (so  
> much so that we made a cron job to do this every 8-12 hours).
> 
> However, rather than abandoning Subversion altogether, we decided to  
> play around with the configuration to see if we could make it an  
> acceptable alternative. The first thing we did was to get rid of Apache  
> 2.0 and mod_svn. Instead we chose to access our repositories via  
> svn+ssh://.... Although this required careful planning of  
> groups/permissions and also necessitated that each developer had a  
> login on the repository machine*, such requirements were not  
> prohibitive in our case. Immediately, we noticed a speedup in checkouts  
> and commits. We also noticed that repository hardly ever got in the  
> "wedged" state we experienced so frequently with mod_svn. For those who  
> wanted continued web access, we used ViewCVS  
> (<http://viewcvs.sourceforge.net/>) which added support for Subversion  
> a while ago and is actually much nicer than the mod_svn web interface.
> 
> In anticipation of the handful of times the repository did become  
> corrupt, we modified the hot-backup.py script that accompanies many  
> Subversion installations and installed it as a post-commit hook** (see  
> <http://svnbook.red-bean.com/svnbook-1.0/ch05s03.html#svn-ch-5-sect 
> -3.6>). We also had a nightly script that did incremental dumps from  
> the repository in the event that we needed to upgrade Subversion and  
> reload (that way we wouldn't have to dump the entire thing and could do  
> a quick upgrade by dumping only those new revisions not covered by the  
> previous night's backup).
> 
> I've attached our svnbackup script*** for reference. We called it in a  
> cron job as follows (this is only for reference, check your version of  
> cron to see if/how it supports commands which span multiple lines):
> 
>     30 23 * * 0     "${HOME}/bin/svnbackup" -d -j -r 0  
> "${HOME}/svnroot" \
>         "${HOME}/svnbackup"
>     30 23 * * 1-6   "${HOME}/bin/svnbackup" -j -l "$(date +\%w)" -r 0 \
>         "${HOME}/svnroot" "${HOME}/svnbackup"
> 
> This used the attached script to create weekly complete backups with  
> daily incrementals.
> 
> If anyone has any questions regarding our experience with Subversion,  
> please feel free to ask. I'd be more than happy to share additional  
> details as requested. I hope this helps!
> 
> Matthew Bogosian
> President/COO, Arena Unlimited, Inc.
> http://arenaunlimited.com/
> 
> Notes:
> 
> * Alternatively, one could create one single user on the repository  
> machine for each repository and allow users to log in as that user  
> (e.g., via ~reposuser/.ssh/authorized_keys). That way, instead of each  
> developer using their own logins for svn commands, everyone uses the  
> same user:
> 
>     svn co svn+ssh://reposuser@svnhost/path/to/repos
> 
> You have to trust your developers not to log in as that user and do  
> stupid things (like delete the repository), but for most teams with  
> which I've been involved, this has never been an issue. If you suffer  
> from OCD (as most good admins do), you can have the repository user's  
> home directory and the repository itself owned by "nobody" or something  
> (so that it's read-only), and only give write access to the  
> repository's db directory to that user's group. Your mileage may very,  
> but I encourage you to experiment. This still allows users to delete  
> the repository, but narrows the field of potential destruction.
> 
> Another alternative (if you have root access to the repository machine  
> or are allowed to run daemons) is to run svnserve in either inetd or  
> daemon mode. For SSL, one can either use the SSL-patched version of  
> svnserve, or one wrap it in an SSL connection with stunnel or ssh. See  
> the svnserve man page or  
> <http://contactor.se/~dast/svnusers/archive-2004-10/0119.shtml> for  
> details.
> 
> ** Warning: hot-backup.py is pretty CPU and disk intensive for larger  
> repositories. The speed of Subversion operations tend to suffer  
> immediately following a commit as a result. They don't fail, they just  
> take a little longer to execute. For example, for those of use who  
> liked to do "svn commit ... && svn update ...", our update took a  
> little longer because the repository machine was still busy doing the  
> hot backup. Another (or faster) CPU, a faster disk (or RAID), more RAM,  
> etc. in the repository machine may make this negligible.
> 
> *** This script requires a posix-compatible environment with Bash  
> version >= 2 installed as /bin/sh (it needs the getopt shell built-in).  
> If you have bash2 installed elsewhere modify the first line to point to  
> that installation. If you run it without any arguments, it will give  
> man-page like instructions on its usage.
> 



-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBgbwyuqamFyFXXLIRApVjAKDFZ8AOFrQmgZOzT44uMn0tWG3+LwCdFSs9
vH4cOwOO8+bs5THwaSfIkUg=
=7gpA
-----END PGP SIGNATURE-----