On Mon, 22 Dec 2008, George Ryan wrote:
>> 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.
I have the same problem. My solution was checking out the whole trunk and
running "svn update -r 0" on the unwanted dirs/files. But since subversion
1.5 I use the 'sparse' feature. Checking out still needs some manual work
but "svn update" and "svn commit" do what what I want (just update what I
have, or commit what I modified).
svn co --depth empty file:///var/opt/repo/trunk wc
svn update --depth empty wc/libs wc/apps
svn update --depth infinity wc/libs/libA wc/libs/libC apps/myapp
Would be nice if this could be done with one commandline. But there are
lots of open questions:
1) Where do we store the information?
Since it depends ond the revision (f.ex. from r123 on myapp also needs
libD) it could be stored in a normal property (probably on trunk/).
2) What if I want to checkout two projects plus dependencies?
3) What if I run "svn update" or "svn update -r 50" ?
2) and 3) sound like a new layer on top of the current subversion API. It
has to find out what the user has, what's missing, which dependency should
be removed.
Just my 2 cents.
Martin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=990012
Received on 2008-12-22 20:28:07 CET