Multi-project organization / repos layout

[Turaukar Yur <yu...@hotmail.com>]

I am struggeling with a proper repository layout to manage multiple projects 
that depend on each other. This is not entirely SVN specific, but the 
available options clearly depend on the features that SVN provides.

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.

What would be the best practices here?
Any suggestions or pointers to articles/websites would be appreciated.

_________________________________________________________________
Die neue MSN Suche Toolbar mit Windows-Desktopsuche. Suchen Sie gleichzeitig 
im Web, Ihren E-Mails und auf Ihrem PC! Jetzt neu! http://desktop.msn.de/ 
Jetzt gratis downloaden!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Multi-project organization / repos layout

[Ryan Schmidt <su...@ryandesign.com>]

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

RE: Multi-project organization / repos layout

[Tom Malia <to...@ttdsinc.com>]

Turaukar,

First, I'll be very curious to hear what the gurus have to say about your
question, as I've been struggling with same for about a week now.

As for the path I'm currently pursuing, I've first decided to create one all
encompassing Repository into which I create sub folders for each actual
separate project/lib/etc.  What I like about this is I can browse that
repository from TSVN and easy see and manipulate everything instead of have
separate Repos and having to have separate browsers open and do exports, and
dumps etc. etc. if I need to copy or move things around.

Second, I'm making extensive use of externals to bring shared code into
projects.  It has required that I restructure a few things into separate
subdirectories, and the management of the external properties can be a pain,
but so far it seems to be working pretty good.


-----Original Message-----
From: Turaukar Yur [mailto:yuraukar@hotmail.com] 
Sent: Tuesday, March 27, 2007 8:34 AM
To: users@subversion.tigris.org
Subject: Multi-project organization / repos layout

I am struggeling with a proper repository layout to manage multiple projects

that depend on each other. This is not entirely SVN specific, but the 
available options clearly depend on the features that SVN provides.

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.

What would be the best practices here?
Any suggestions or pointers to articles/websites would be appreciated.

_________________________________________________________________
Die neue MSN Suche Toolbar mit Windows-Desktopsuche. Suchen Sie gleichzeitig

im Web, Ihren E-Mails und auf Ihrem PC! Jetzt neu! http://desktop.msn.de/ 
Jetzt gratis downloaden!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org