Reintegrate woes
We have been working for a long time (almost a year) on two products in paralell. One is a maintenance product, i.e. general bug fixes and very little new features, called base and is effectively trunk. The other is a new and improved with all the latest bells and whistles, and is handled in a branch. Both of them are divided into ca. 80 sub-products, 10% unique and 90% common, of which roughly 20% of the latter are branched. As both teams progressed they fixed bugs or added features in their respective product, hence it was necessary to merge both from branches to trunk and vice versa. Now comes the time to merge branches back to trunk and I try with a: ft@halt:/proj/.../ecom_spusvn merge --reintegrate file:///home10/svn/.../ecom_spu/branches/foo . Sometimes this works as expected, but on most occasions I get: svn: Reintegrate can only be used if revisions 1413 through 2204 were previously merged from file:///home10/svn/.../ecom_spu/trunk to the reintegrate source, but this is not the case: ecom_spu/branches/foo Missing ranges: ecom_spu/trunk:1413-1707,1709-1852,1854-1855 I take it that meas that svn has detected that something has gone from branches back to trunk on an earlier occasion? Isn't it really necessarry to break reintegrate like this? svn has all the relevant information of which revisions have gone where. And I can perform the merge by doing: ft@halt:/proj/.../ecom_spusvn merge -r 1413:2204 file:///home10/svn/...ecom_spu/branches/foo . --- Merging r1414 through r1422 into '.': Uecom_edhipc_decl.ads Umtt_gateway.adb --- Merging r1424 through r1527 into '.': Gecom_edhipc_decl.ads Gmtt_gateway.adb --- Merging r1597 through r2204 into '.': Uecom_spu_1.adb Uecom_spu_socket.ads Gecom_edhipc_decl.ads Uecom_spu_socket.adb Gmtt_gateway.adb Or am I missing something here? Regards, -Frode -- ^ Frode Tennebø | email: frode.tenn...@saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
RE: Database Corruption in SVN
Is there any way that SVN database may be corrupted. Any story , Issue , Experience.. The only time I have encountered this was when a collegue set up a BDB repository and accessed it using file:/// on an NFS mounted disk from several clients. -Frode
RE: error message in configuaring subversion
i have problem in seting up variable or installing the subvision can u help with the steps i have attache the arror massage 1) Never send attachments to this list (or any other lists which does not explicetedly allow this in their charter). 2) You sent an image inside a proprietary format. Never, ever do that. What you should have done instead of 1) and 2) above is to put the image on any of the image/file hosting sites available and give the URL, or even better, just cut-n-paste the appropriate text into the mail. To answer you question: You need to install subversion (http://subversion.apache.org/packages.html#windows) and make sure you Path environment variable (System - Advanced - Environment Variables) points to the directory you have installed Subversion to. -Frode
Multiple svn chekcouts in the same top-level hierarchy
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 . Alibrlib Alibrlib/lib Alibcru Alibcru/lib Alibhci Alibhci/lib Aretrieve.sh Alibcau Alibcau/lib : : One of the files retrieved is the script retrieve.sh which in turn retrieves ~100 different products from my repository: # ./retrieve.sh svn co svn+ssh://halt/basis_sw/BIS/cau1192127_3_lr/trunk libcau/lr Alibcau/lr/game_realtime_logger.adb Alibcau/lr/game_log_file.ads Alibcau/lr/game_replayer.ads Alibcau/lr/eres.adb Alibcau/lr/game_log_replay_decl.ads : : svn co svn+ssh://halt/basis_sw/BIS/cau119_4_bis_eval/trunk libcau/bis_eval Alibcau/bis_eval/bis_site.adb Alibcau/bis_eval/bis_site.mk : : etc. (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: # svn st . ? libcau/lr ? libcau/bis_eval : : # svn st libcau ? libcau/lr ? libcau/bis_eval : : # svn st libcau/lr # svn st libcau/bis_eval (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/* 0.092u 0.119s 0:01.48 13.5% 0+0k 0+0io 0pf+0w 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/* At revision 917. At revision 917. : 3.064u 2.589s 2:13.39 4.2% 0+0k 5352+0io 1pf+0w 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 -- ^ Frode Tennebø | email: frode.tenn...@saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
RE: SVN Relay
Ok, but that's not what i we at work. The local svn will be a working copy of the external svn. In fact, no user have to use the external svn if there's a local svn. The goal of this is the limit the access to the WAN. In that case the WAN repository can be looked on as a mirror/off-line backup of the LAN repository. You could use rsync to keep an up-to-date mirror on the WAN while the LAN is the active server. You need to set up an svn installation on the LAN, rsync (or some other form of copy) the initial repository from the WAN server to the LAN server. All uses now use the LAN repository. Some cron-job automatically rsyncs the LAN repository back to the WAN server. Make sure that only this mechanism can touch the WAN repository or you are FUBARed. -Frode -- ^ Frode Tennebø | email: frode.tenn...@saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
RE: Checking: svn: '/foo/libcau' is not a working copy
Ryan, AFAIK if you're going to commit several things at once, they need to all reside in a common parent directory that is a working copy of the same repository. Thanks for your help. While not immediately obvious, this was in fact the problem. Also, thank you for your time and effort on the list to help us less experienced with the intricacies of SVN. Regards, -Frode -- ^ Frode Tennebø | email: frode.tenn...@saabgroup.com ^ | Saab Technologies Norway AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
Checking: svn: '/foo/libcau' is not a working copy
When I try to check in several directories I get the following error: f...@tr:/foosvn ci lib*/* Checking: svn: '/foo/libcau' is not a working copy f...@tr:/foosvn ci librlib/* libhci/* libcru/* libcau/* Checking: svn: '/foo/libcau' is not a working copy The error-message in itself is correct; 'libcau' is not under version control, nor are any of the other top-level directories. However, inside these directories I have sub-directories which contain the actual code: f...@tr:/fools -l libcau/ total 184 drwxrws--- 3 ft ftgr 4096 2010-05-07 09:10 adt drwxrws--- 3 ft ftgr 4096 2010-05-19 09:33 bal drwxrws--- 3 ft ftgr 4096 2010-05-19 09:33 bis_eval drwxrws--- 3 ft ftgr 4096 2010-05-07 09:09 bis_utl drwxrws--- 3 ft ftgr 4096 2010-05-19 09:33 clt_ctrl drwxrws--- 3 ft ftgr 4096 2010-05-19 09:33 dbc_err : So, normal shell (this is linux) expansion should not include 'libcau' (on it's own) in the list of directories to be committed. And indeed, testing with a different svn command yields: f...@tr:/foosvn st lib*/* Status against revision:894 Status against revision:894 Status against revision:894 Status against revision:894 : ...all fine, and: f...@tr:/foocd libcau/ f...@tr:/foosvn st . svn: warning: '.' is not a working copy ...as expected. What is going on? -Frode
