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

Re: Mimicing CVS modules in Subversion

From: George Ryan <gryan_at_akoostix.com>
Date: Mon, 22 Dec 2008 12:12:50 -0400

> I'm sorry, but this list is for the development of Subversion itself,
> not about the usage of Subversion, nor is it an appropriate place to
> "escalate" issues from the users list. If you can make a specific
> design proposal for how to accomplish what you want, it could be
> considered for a future release.

No need to apologize for my faux-pas. I am more than willing to work on
a design proposal for what I need. :-)

I guess my proposal would be to add something akin to a property
like "svn:internals" that would allow for the specification of a repo
URL and the check out relative paths based on that base URL.

file:///var/opt/repo/trunk \
        libs/libA \
        libs/libC \

and that all of these would be 'jointed' together so that a commit
from the root would recurse down the heirarchy as would be expected.

Right now, I can specify multiple paths to "svn co", but they are
disjointed. Also it doesn't scale well from the command line in the way
that svn:externals does. In some cases applications could use dozens of
libraries that have their own inter-dependencies. That's a lot to ask
from the command line.

> However, you should be aware that Subversion 1.6 will include support
> for file-based externals (as opposed to directory based). This will
> probably go a long way towards what you want.

Actually, I think this migh make my situation even worse. Not only would
I have to be aware of all of the inter-library dependencies manually, I
would have to have an external for every file in all of the libraries
and keep that list up-to-date when files are added and removed in
dependent externals. I suspect externals properties just isn't what I

> But it will still take
> planning your repo structure to facilitate this. I'm sure this is cold
> comfort, but in my opinion this is really a project build issue, rather
> than a source control management feature.

Perhaps you are correct, however as I (and many others before me) wrote
in my previous email, there isn't a satisfactory way to plan a repo
structure that duplicates the required functionality. In all of the
scenarios I listed, a solution is either error-prone or ends up being a
substandard answer.

Received on 2008-12-22 18:07:42 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.