Re: Multi-project organization / repos layout

On Mar 27, 2007, at 07:33, Turaukar Yur wrote:

> Let's say we have a library project libA (I will use java as an
> example, but this should apply for basically most programming
> environments). libA might depend on a number of 3rd party jars that
> should be in svn along with the source for libA itself.
> Let's say we have another library project libB. libB uses libA and
> therefore should somehow link to the libA repository.
> Finally we have productA, which uses libB and libA directly.
>
> My first attempt has been to have libA organized as
> libA/trunk
> lib/trunk/src (containing all source code)
> libA/trunk/lib (containin all 3rd party jars)
>
> and have libB organized as
> libB/trunk
> lib/B/trunk/src (containing all source for libB)
> libB/trunk/lib (containing all 3rd party jars that only libB uses)
> libB/trunk/lib/libA (svn:external pointing to libA/trunk)
>
> However, when I continue to follow this structure, projectA ends up as
> projectA/trunk
> projectA/trunk/src (containing all source for project)
> projectA/trunk/lib (containing all 3rd pary jars that only this prj
> uses)
> projectA/trunk/lib/libB (svn:external pointing to libB/trunk)
> projectA/trunk/lib/libA (svn:external pointing to libA/trunk)
>
> When checked out, this results in libA being downloaded twice - not
> a very smart idea. If I omit the second svn:external, then libA is
> only available as lib/libB/lib/libA. I like neither result.
>
> SVN is apparently a very nice tool for version control and lots of
> best practice hints are given (along with the famous trunk/tags/
> branches approach). However, little to no guidance is provided as
> to how to manage dependencies.

I would say you have two options. One is to do it the way you've done
it, where libB defines a dependency on libA using externals, and you
accept the fact that if projectA needs to use both libA and libB,
libA will get downloaded twice. The other option is that libB does
not define a dependency on libA using externals. Instead, it includes
a documentation file explaining how to use libB, and it says that you
must make libA available in your project in order to use libB. The
latter is the approach I am currently taking in my libraries.

My libraries generally have the structure:

libC/trunk
libC/trunk/libs
libC/trunk/examples
libC/trunk/examples/example1

The libs directory contains the libraries you would actually want to
use in your project; in your project, you would define an external
pointing at libC/trunk/libs (or, better, at a particular tag of
libC). The examples directory contains various examples showing how
to use the library. The various examples define externals pointing at
the various other libraries libC may require. In this way, if you
check out the entire trunk, you get libC plus all dependencies and a
set of examples that work properly. And if you just point to the libs
directory from your project with externals, you just get libC, and
can bring in any other libraries on your own time.

Now, my libraries are JavaScript and this strategy works fine for me.
Since you're talking about jars I guess you're using Java, and I
haven't written any Java so I'm not sure if the strategy will work
for you.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org