> 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 \
apps/myapp
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
need.
> 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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=989882
Received on 2008-12-22 18:07:42 CET