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

Mimicing CVS modules in Subversion

From: George Ryan <gryan_at_akoostix.com>
Date: Mon, 22 Dec 2008 09:11:51 -0400

I posted some questions on the user's list, but didn't get much traction
there. Perhaps someone here will have more insight. Thanks!

I've been trying to some up with an adequate scalable solution for
building apps using libraries pulled in via external properties, either
from multiple repos or the same repo. Basically what I need to do is to
mimic CVS modules. However every method I've tried has unfortunate

1. Using svn:externals is okay in the simple cases, but when libraries
begin to start depending on other libraries, it's possible to end up
with multiple copies of the same externals somewhere in the tree,
because the externals are disjoint and don't know about each other. This
is both wasteful in time and space, but also error-prone if I edit and
commit one copy and don't update the other.

2. I can't solve (1) because I can't specify the same destination
directory for more than one external. Copying files to a staging area
before building is also error-prone and simply complicates the entire
build process and I'm just asking for someone to edit the wrong file.

3. I can't really do multiple pruned checkouts from the top level of a
single repository, because that doesn't scale, either. You can't check
in from a top-level directory because they are disjointed. Also, I have
to hack in place some kind of script that triggers individual directory
checkouts because we can't type 25 separate library paths on the command
line and that is just making me immitate a poor-man's CVS modules. I
end up with a meta-tool that runs Subversion. Seems wrong.

4. Someone on the user's list suggested I take the idea in (3) and
make a separate repository for manifests to build an app using externals
definitions. I could get around the recursive problems in (1) if I
flattened the hierarchy, but then this leads to other non-scalable
problems such as having to manually remember every dependency of every
library used and manually enter it. Plus, because everything has to be
in a separate directory for externals, again I have to make some kind
of pre-build staging area that contains all my headers laid out how they
need to be in order to avoid borking the compiler with a '-I' include
line that spans O(n) library files.

I've seen this problem mentioned in various ways in the mailing lists
going back several years and as yet there doesn't seem to be a proper
solution to the problem. Right now it's a significant enough problem
that I am considering moving back to CVS (yuck).

I don't know much about how the internals of Subversion works, but I
would be more than willing to invest some of my time to work on coming
up with a scalable solution for assembing pieces of one or more
repositories in a way that works well.

Also, if anyone has any other suggestions on how to lay out a repo or
to use externals in a way that might give me the effect I need, that
would be great.

George Ryan
Senior Software Architect
Akoostix Inc., Nova Scotia Canada
902-404-PING | www.akoostix.com

"Simplicity and elegance are unpopular because they require hard work
and discipline to achieve and education to be appreciated."
- Edsger W. Dijkstra

The information contained in this e-mail may contain confidential
information intended for a specific individual and purpose. The
information is private and is legally protected by law. If you are not
the intended recipient, you are hereby notified that any disclosure,
copying, distribution or the taking of any action in reliance on the
comments of this information is strictly prohibited. If you have
received this communication in error, please notify the sender
immediately by telephone or return e-mail.

Received on 2008-12-22 14:29:45 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.