Multiple svn chekcouts in the same top-level hierarchy
From: Tennebø Frode <frode.tennebo_at_saabgroup.com>
Date: Tue, 21 Sep 2010 11:35:56 +0000
I have a setup where I have a help-structure which I check out as normal:
# svn co svn+ssh://halt/Products/Foo/lzy202432_13_application_sw/trunk .
One of the files retrieved is the script "retrieve.sh" which in turn retrieves ~100 different products from my repository:
# ./retrieve.sh
(We do this as we version control each of these products separately with design, QA, etc. handled through a corporate process (and a separate tool) and they are reused in multiple projects.)
There are at leat two issues I have with my current setup compared to the "normal" way of just retrieving everyting in one go.
1) If I do "svn st ." I get:
(The last two works fine.)
I.e. svn does not recurse into sub-directories which are under svn control, but not an immediate decendant. I have to specify the top-level directory (or wildcard) for which the "svn co" command was done. Is this the way it should or must be, or coulnd't the client figure this out and recurse as necessary?
2) Speed. Because of 1) I need to perform something like this for a status:
# time svn st libcau/* libcru/* libhci/* librlib/* CXC/* hci/* server/*
1.5 sec, which is fine. However, talking to the server is *very* time consuming:
# time svn st -u libcau/* libcru/* libhci/* librlib/* CXC/* hci/* server/*
The exact same setup, but using file:/// instead of svn+ssh:// takes ~6 seconds. That's 20x - close to unusable. :( Is there anything which can be done to speed things up? I have done what I know of how to tune the ssh sesion, but only gained a few %.
Regards,
-- ^ Frode Tennebø | email: Frode.Tennebo_at_saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |Received on 2010-09-21 13:37:22 CEST |
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.