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

Layout for hierarchical code dependencies (externals enhancement?)

From: Sonnenmoser Kurt <Kurt.Sonnenmoser_at_aris-geoservices.ch>
Date: 2007-08-14 17:36:55 CEST

Hi

I'm new to Subversion and trying to define a meaningful way to handle
hierarchical code dependencies.

Say, we have a project composed of separate code components, A, B, and
C, with the following dependencies (the arrows mean "depends on" or
"uses"):

    A -> B
    A -> C
    B -> C

Using the svn:externals property on A and B, I can easily generate the
following directory layout with one check-out:

MyProject/
  A/
    B/ (I)
      C/
    C/

But I would prefer the following:

MyProject/
  A/ (II)
  B/
  C/

I.e.,
- Hierarchically dependent components should not appear as sub-
  directories.
- C should not be checked out twice, as in (I).
- If A does not directly depend on C, MyProject or A should not have
  to "know" that C should be checked out.

I'm tending to wish for the following enhancement to SVN externals:
- allow the target directory of an externals definition to start
  with ".."
- noticing at check out that the same repository URL is checked out
  twice to the same location and therefore checking it out only once

I could not find a corresponding enhancement request in the issue list
and I'm beginning to wonder if there's something wrong with my approach
and if our needs could be satisfied differently. (At the moment, to
achieve layout (II), we envision that MyProject explicitly references
B and C as externals.)

Any hint about how others have solved (or not solved) this problem, or
whether others would also like to see the mentioned enhancement, would
be very much appreciated.

Kurt

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 14 17:45:12 2007

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