[SM-Discuss] SVN as p4 replacement

Sergey A. Lipnevich sergey at sourcemage.org
Mon Mar 20 15:07:51 EST 2006


Seth Woolley wrote:
> By split I mean stuff that could be compiled with one spell are split 
> into multiple spells that need more enhanced relationships between them 
> than normal dependencies.  I don't mean subversion is a split spell, but

Sub-depends is the answer to that I think. But there's only one 
sub-dependency I see for Subversion: mod_dav inside apache2 if you pick 
an option to build an apache module. But, you don't need this option for 
"svn" client or for "svnserve" server to work. If it's not "off" by 
default already, maybe it should be.

>  
>
> Things like apr|apr0 apr-util|apr0-util for example.  It might not even 
> be related to this as it failed on a compile error I didn't take a look 
>   

APR is tricky because we still keep Apache 1.3. We either have to remake 
apr0 spells to coexist with apr spells, or get rid of apr0 completely in 
favor of building and installing the whole apache 1.3 server in some 
designated path. This way, we could strongly tie Subversion with apr (1.x).

> If there's a way, as mentioned previously, to not require anything 
> apache-related to build svn, I'd be greatly for that.  It's not that 
>   

Well, is there a way to build everything without glibc ;-)? Subversion 
needs at least apr and apr-util (both at same version 0.9 or 1.x), and 
there's no way around that. This design decision was made very long time 
ago, and I believe part of the reason was to support both Windows and Linux.

> All I'm saying is that before we switch to anything, I'd like to know 
> that I can expect our own system to build it reliably in cases we care 
> about.  This is currently not the case for subversion.
>   

I agree that whatever we switch to must work, no question about that. 
However, I'm sorry so say that your experience alone is not 
representative. Relatively small but important part of the reason of why 
Subversion spell is more complex than average is that we want to 
preserve choice, and navigating that choice is not straight-forward 
sometimes.

Sergey.



More information about the SM-Discuss mailing list