Andreas Jung wrote:
> <john.peacock_at_havurah-software.org> wrote:
>> This will always work:
>>
>> $ svn update external_that_changed
>>
>
> You're wrong - this does not work (as described).
That's interesting; I tested before I sent the message. Perhaps we are having a
failure to use the same notation. This is what I am describing:
wc
\_dir-1
\_dir-2
\_external-1
\_external-2
where dir-1 and dir-2 are normal folders in the checkout path and external-1 and
external-2 are externals to some other path.
From the root of the working copy, typing 'svn up external-1' updates only the
external-1 subtree. Are you not seeing that behavior? In fact, as far as I can
tell, the following two commands are completely identical in effect:
$ svn up external-1
$ cd external-1 && svn up && cd -
> In a project like Zope 2 we work without around 100 svn externals and updating a complete source tree might take some minutes - especially
> because svn re-opens a new ssh+svn connection for each external definition.
svn+ssh is pretty much the worst-case scenario for that kind of operation,
because the connection startup time can quickly become a significant percentage
of total runtime. Normally externals are all considered to be different
repositories (even when they aren't), so even with Apache/mod_dav, you won't get
any connection reuse.
However, if these are most/all 'in-tree' externals (meaning paths in the same
repository), then I would expect the performance to be [much?] better using the
new relative externals introduced in 1.5.0 (since the client will now know for
certain that the externals are the same repository as the main checkout (and
hence can reuse connections). I'm not sure whether svn+ssh will gain as much as
http[s] would gain, though. It may be that you want to rethink your repository
access method to stop using svn+ssh...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-07 02:57:29 CEST