[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
More information about the SM-Discuss