Subversion

Well, we went ahead and did it; switched from Visual Source Safe to Subversion. Ahh. The producers see TortoiseSVN and want it, so our data will be going over soon too. Right now we’re running VisualSVN server on our Windows file server and their client for Visual Studio.

I’m now trying to set up commit hooks and running into brick walls. I wanted to avoid having to write something myself and though the Ruby commit-mailer.rb sounded promising. Except, it appears that Ruby no-longer ships with ruby-svn and I can’t figure out where the heck you would get it from.

So, I guess I’ll do something with the Perl version. That’s not so bad, really, I can make it announce commits to the IRC server while I’m at it :) Or, more likely, have it write the announcements to a database and let something else pick them up.

11 Comments

How large are your data files? I’ve had experience adding large files (200Megs) and having them become corrupt. I’ve also heard rumors of SVN not handling binarys very well.

Take a look to this knowledge base article how to configure email notifications in VisualSVN Server 1.6 beta:
http://www.visualsvn.com/support/topic/00018/

Doh, thanks, Ivan, I’ll probably switch to that… My solution had been to go with the commit-email.pl from tigris.org (slightly modified), I have it set to:

“c:\program files\visual svn\bin\commit-email.pl” %1 %2 -h playnet.com -r coders@playnet.com -s “[svn:commit]” coders@playnet.com

I was about to add a crude IRC interface to it commit-email.pl so that it would announce it to our internal IRC server:

use IO::Socket::INET ;
use Time::HiRes qw(usleep);

our $IRCSock = 0 ;
our $IRCHost ;
our $IRCConnected = 0 ;

sub ircQuit (;$)
{
my ($text) = (@_) ;
my ($quitText) = ($text ? ” :$text” : “”) ;

$IRCSock->send(“\nQUIT${quitText}\n”) ;
$IRCSock->shutdown(SHUT_RDWR) ;

usleep(250 * 1000) ;

close $IRCSock ;

$IRCSock = 0 ;
$IRCConnected = 0 ;
$IRCHost = “” ;
}

sub ircConnect($$)
{
my ($user, $pass) = (@_) ;

ircQuit() if ( $IRCSock ) ;

$IRCSock = IO::Socket::INET->new(PeerAddr => ‘192.168.0.81’, PeerPort => ‘6667’
, Proto => ‘tcp’, Type => SOCK_STREAM, TimeOut => 3000, Blocking => 0) ;
if ( !$IRCSock )
{
warn “WARN: Unable to open IRC Socket\n” ;
return 0 ;
}

for ( $i = 0 ; !$IRCSock->connected() && $i < 50 ; ++$i ) { usleep(1000) ; } if ( !$IRCSock->connected() )
{
$IRCSock = 0 ;
warn “WARN: Unable to connect to IRC Server\n” ;
return 0 ;
}

$IRCSock->send(“\nPASS $pass\nNICK $user\nUSER $user $user $user :$user\n”) ;
for ( $i = 0 ; $i < 3000 ; ++$i ) { usleep(10 * 1000) ; $IRCSock->recv($text, 40960) ;
next unless ( $text ) ;
$IRCHost = $1 if ( $text =~ /^:(\S+)\s+001\s+$user\s+/m ) ;
{
$IRCHost = $1 ;
$IRCConnected = 1 ;
last ;
}
}
if ( !$IRCConnected )
{
ircQuit() ;
warn “WARN: Unable to log in to IRC Server\n” ;
return 0 ;
}

return 1 ;
}

sub ircLogin($;$)
{
my ($user, $channels) = (@_) ;

ircConnect($user) or return 0 ;

if ( $channels )
{
$IRCSock->send(“\nJOIN ${channels}\n”) ;
}

usleep(250 * 1000) ;
}

sub ircMessage ($$)
{
my ($channels, $message) = (@_) ;

ircPing() ;

foreach $channel ( split(/,/, $channels) )
{
$IRCSock->send(“\nPRIVMSG $channel :$message\n”) ;
usleep(60 * 1000) ;
}
}

sub ircPing ()
{
my $pingHost ;
for ( $i = 0 ; $i < 5 ; ++$i ) { $IRCSock->recv($text, 65536) ;
$pingHost = $1 if ( $text =~ /^PING\s+.*:(\S+)\s*$/m ) ;
usleep(1000) unless ( $pingHost ) ;
}

return unless ( $pingHost ) ;

$IRCSock->send(“\nPONG :$pingHost\n”) ;
}

The emailer part is working but the overhead of starting Perl to run commit-email slows operations down a bit, and I was thinking a compiled solution might be better :)

Ah! Version 1.6 – not yet released – now I don’t feel quite so dumb for not spotting that myself :)

What? No beta for managing your production data?

VisualSVN Server 1.6 beta contains latest stable Subveresion 1.5.3. So you can use this beta without risk.

Good luck with SVN .. it’s super slow :) I’d have recommended CVS, it’s a lot faster and has just about all the features.

Would it be noticeably slow for a team of CRS’ size, though, or is that a scaling issue?

Actually, it seems like some of the major points of SVN 1.5 are performance related.

SVN is a winner for it’s Windows UI (TortoiseSVN) and those handful of features that CVS didn’t have (svn:externals, /very/ handy for external open source projects), and the fact that SVN is the /one/ RCS that /all/ of our IDEs supported other than Perforce.

Trackbacks and Pingbacks

[…] Our switch to subversion has finally begun creaking the way I said it would and several of you insisted it wouldn’t. SVN has been a damned hindrance this dev cycle. SVN is fine if you are a big corporate development team with the assurance of a one way flow of changes. But if stuff starts feeding in multiple directions, the old conflict monster starts to rear its head in the worst ways. And last week we got into a state where SVN can’t even reverse merge one set of changes… […]

[…] Moving from VSS to Subversion (and then possibly Mercurial) varies in complexity depending on your repository. Ours is ten years old and contains multiple projects, which have danced around the directory tree. […]

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: