> 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
Received on Tue Aug 29 15:54:06 2006