Re: Query: svn externals and export
From: Ryan Schmidt <subversion-2009d_at_ryandesign.com>
Date: Thu, 10 Dec 2009 04:35:13 -0600
On Dec 10, 2009, at 03:14, Andrew Hardy wrote:
> On Dec 9, 2009, at 12:34, Ryan Schmidt wrote:
>
Yes it would, if by "etc." you mean the contents of the .svn directories.
> and effectively double the data downloaded.
There is no difference in the amount of data downloaded from the repository server to the client between the checkout and export command. The difference is that the checkout command makes a second copy of the files on the client, and adds additional administrative data, in the .svn directories. So the only "problem" with a checked out working copy is the extra disk space it takes on the client; you'll have to compare the disk space available with the size of your project to know if this is going to be a problem.
The advantage of the working copy is that you can update it to the latest version simply, and only the differences are transferred over the wire, whereas if you only had an export, you'd have to export the whole thing again to get the updated version.
> I think that I'll have to export the 'trunk' to a temporary position and then copy the required directories, etc. to the final build location. A little messy...
There's no reason you couldn't directly use repository URLs to read the svn:externals properties. But I don't see much difference procedurally between using a working copy and using an export. They're both messy, the way you want to have it. You'll check out (or export) the trunk in some non-infinite depth, read the svn:externals properties in it (either out of the working copy or from the repository URLs), then check out or update (or export) additional directories inside, possibly recursively.
------------------------------------------------------
Please start new threads on the <users_at_subversion.apache.org> mailing list.
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.