svn:externals and shared projects

[Sander van der Wal <sv...@mBrainSoftware.com>]

A quick question about using svn:externals and multiple libraries

Lets say I have project A, library B and Library C. These are all separate
folders in a repository, with the usual layout. There is a need for B and C
to be different projects, project D also uses B and C, and project F uses C
too. 

In this case, Project A uses library B and Library C. Library B also uses
Library C.

If I use svn:externals to connect B and C to A and C to B, I think I would
get the following folder structure in the sandbox.

Project A
    docs
    src
    library B | folder pulled in because of svn:externals mapping B to A
       docs
       src
       Library C | folder pulled in because of svn:externals mapping C to B
           docs
           src
    Library C | folder pulled in because of svn:externals mapping C to A
        docs
        src

i.e There are two copies of Library C in the sandbox.


Best regards

Sander van der Wal
www.mBrainSoftware.com 


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

Re: svn:externals and shared projects

[Andy Peters <de...@latke.net>]

On Aug 29, 2006, at 6:45 AM, Sander van der Wal wrote:

> Which means you introduce a dependency between A' (the A that  
> doesn't use
> C), that isn't there in the design, and in addition the include  
> paths for B
> now depend on A'. This introduces another dependency between A' and  
> B (the
> wrong way around) so there is now a dependency cycle between A' and  
> B. Which
> isn't in the design either.
>
> Basically , this means that unless the design of the system is  
> layered and
> code can only depend on code in the layer below, and each layer is a
> separate project, svn:externals is dangerous.

I've found that the best way to handle this is to ensure that  
anything you use as an external is itself its own project, and  
furthermore, I always use a tagged version of anything that's brought  
in as an external.

In other words, I always use non-changing lower-level "modules" in a  
project.

Here's why.  I do FPGA designs using VHDL, but I imagine that this  
applies to any generic project.  Say I've designed a UART module, an  
SPI module and an LCD interface module, and I include them in my main  
design using externals.  I build a chip, simulate it, test it, and  
declare the chip to be "good," so I tag the sources for my chip,  
release it, and move on to the next project.

Some time later, for whatever reason I need to go back to that  
design, so I check out the tag to see what I released.  However, in  
the time between releasing the chip and revisiting it, the UART  
module was modified.  If I've included the UART module's trunk in my  
design, when I check out the tag, it checks out the newer version of  
the UART module, NOT what was used to build the chip!

Of course, during development, it's reasonable to use the trunks of  
submodules, since those modules might need to change, and using the  
most recent versions is reasonable, anyways.  But when you tag  
something for release, you want to make sure that what you tag will  
always give you what you think you tagged, so the solution is to  
ensure that the tagged main project uses only tags for submodules and  
never their trunks or branches.

-a

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

RE: svn:externals and shared projects

[Sander van der Wal <sv...@mBrainSoftware.com>]

> On Aug 29, 2006, at 10:26, Sander van der Wal wrote:
> 
> > A quick question about using svn:externals and multiple libraries
> >
> > Lets say I have project A, library B and Library C. These are all 
> > separate folders in a repository, with the usual layout. There is a
> need for
> > B and C
> > to be different projects, project D also uses B and C, and project
> > F uses C
> > too.
> >
> > In this case, Project A uses library B and Library C. Library B also 
> > uses Library C.
> >
> > If I use svn:externals to connect B and C to A and C to B, I think I 
> > would get the following folder structure in the sandbox.
> >
> > Project A
> >     docs
> >     src
> >     library B | folder pulled in because of svn:externals mapping B 
> > to A
> >        docs
> >        src
> >        Library C | folder pulled in because of svn:externals
> > mapping C to B
> >            docs
> >            src
> >     Library C | folder pulled in because of svn:externals 
> mapping C
> > to A
> >         docs
> >         src
> >
> > i.e There are two copies of Library C in the sandbox.
> 
> There sure are. :-)
> 
> As I see it, your options are:
> 
> 1) Accept it. Project A uses Library B and its copy of
> Library C, and  
> Library B uses its copy of Library C.

Ok, with the possibility that the two copies will go out of synch. This is
bound to happen as soon as one starts to use branches instead of the trunk.
 
> 2) Project A knows that Library B includes Library C, so Project A
> only includes Library B via externals and uses Library B's copy of  
> Library C.

When you specify include paths to C for A, it looks like C is a part of B,
instead of a separate entity. This makes the implementation different from
the design, and is a recipe for problems.

> 3) Library B doesn't include Library C but requires that the project
> into which it's included does so, and Library B then accesses the  
> copy of Library C available one level higher.

Which means you introduce a dependency between A' (the A that doesn't use
C), that isn't there in the design, and in addition the include paths for B
now depend on A'. This introduces another dependency between A' and B (the
wrong way around) so there is now a dependency cycle between A' and B. Which
isn't in the design either.

Basically , this means that unless the design of the system is layered and
code can only depend on code in the layer below, and each layer is a
separate project, svn:externals is dangerous. 

Best regards

Sander van der Wal
www.mBrainSoftware.com 


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

Re: svn:externals and shared projects

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

On Aug 29, 2006, at 10:26, Sander van der Wal wrote:

> A quick question about using svn:externals and multiple libraries
>
> Lets say I have project A, library B and Library C. These are all  
> separate
> folders in a repository, with the usual layout. There is a need for  
> B and C
> to be different projects, project D also uses B and C, and project  
> F uses C
> too.
>
> In this case, Project A uses library B and Library C. Library B  
> also uses
> Library C.
>
> If I use svn:externals to connect B and C to A and C to B, I think  
> I would
> get the following folder structure in the sandbox.
>
> Project A
>     docs
>     src
>     library B | folder pulled in because of svn:externals mapping B  
> to A
>        docs
>        src
>        Library C | folder pulled in because of svn:externals  
> mapping C to B
>            docs
>            src
>     Library C | folder pulled in because of svn:externals mapping C  
> to A
>         docs
>         src
>
> i.e There are two copies of Library C in the sandbox.

There sure are. :-)

As I see it, your options are:

1) Accept it. Project A uses Library B and its copy of Library C, and  
Library B uses its copy of Library C.

2) Project A knows that Library B includes Library C, so Project A  
only includes Library B via externals and uses Library B's copy of  
Library C.

3) Library B doesn't include Library C but requires that the project  
into which it's included does so, and Library B then accesses the  
copy of Library C available one level higher.


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

Re: svn:externals and shared projects

[Oliver Frick <gu...@yahoo.de>]

Hello Sander,
we had a similar problem in our workgroup and have found
the following solution to be useful:

Our repository is subdivided into basic directories:
/apps, /lib, /projects (and others)

Every application subdirectory contains only it's own resources
(source code etc), but no libraries, not even externals-refs to them.
For every application we create a second subdirectory (currently
located in /projects) that pulls together the application's stuff and
additional resources. Everything is linked via externals properties
here. The externals properties assemble a compilable application 
by placing all resources in a directory structure that mirrors our 
repository top-level, i.e. 

/myAppProject/apps/myApp (here without the trunk/branches etc)
/myAppProject/lib/libA
/myAppProject/lib/libB  ... etc.

The make files of the application (or a VisualStudio project etc.)
can then be configured to look for the additional stuff
in the respective directories relative to the checked-out app-dir
(e.g. "../../lib/libA").  
It works even better for us, since we use our applications in 
different configurations. Some applications are not only used standalone 
but sometimes as part of a larger project consisting of  multiple
apps, so the libraries - which are used in many of our applications -
would have to be checked out and compiled multiple times. With
the method above they are only checked out and compiled once for
all applications in the project.

Oliver

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