[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Large project architecture and similarities to Svn

From: Matt England <mengland_at_mengland.net>
Date: 2006-03-30 21:57:22 CEST

Hello,

I'm looking for perspectives on how to manage the source for these external
libraries. Details below.

Details:

I'm an experienced Subversion admin and user. I am also managing a large
software endeavor that is about to be introduced as open-source project. I
hope it's ok to post the developers list, for my questions seem better
directed towards those managing the development project (I think).

I see several similarities between my project and Subversion, namely that
we use several external libraries much the same way that Subversion
leverages apr and neon (and possibly others).

I'm looking for perspectives on how to manage the source for these external
libraries. I see in the current trunk
(<http://svn.collab.net/repos/svn/trunk/>) that there is no 'apr' nor
'neon' directory as documented per
<http://subversion.tigris.org/hacking.html#directory-layout>. Are these
vendor-external source sets still managed by Subversion? Last time I build
svn (from a 1.3.0 tarball) I recall the src tarball including apr and neon
software.

Right now I'm weigh my project's options for managing this external
source. Our current build farm/development machines current checkout
header files and binary libraries (both static and dynamic) from a
controlled repo in order to build the application binaries for our
stuff. However, I think we are reaching our limit for this applicability,
in that some external library binaries may be too platform/environment
dependent (eg, Debian3.1-stable boost 1.32.0 libs built under an older
version of gcc/g++ don't work well on Debian3.1-testing, etc)...and thus
there are benefits to building everything from source (separate from a
package-file/.rpm/.deb install which requires the right libs be
installed/available).

The question is...how to manage this? I figure the source for these
projects is best distributed in a big tarball like Subversion does? Or
not? What about the repo management--should said source be in there in the
apparently-classic 'external vendor' management? It sure would help in the
event we want to edit said source.

For what it's worth, our current list of external mechanisms/libraries are
as follows:

ACE (Adaptive Communication Environment)
Boost C++ libraries (3-5 libs thus far, probably more over time)
BZip compression
OpenSSL cryptogorphy and networking
libpqxx: PostgreSQL C++ interface
Xerces-c XML parser
Ptypes network interface (optional)
SQLite database libraries (optional)

I can provide more info as needed. I'm in the early stages of researching
this stuff, so please pardon any ignorant questions. I'm probably going to
go browse around the Apache development area next to see what they do and
if they face similar challenges.

-Matt

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 30 21:58:04 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.