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
Received on Wed Aug 30 22:44:49 2006