Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
On Mon, 14 Aug 2006 01:02:20 +0100, Tony Hoyle <tony.hoyle at march-hare.com> wrote: >David Somers wrote: >>> When I look to the bug reports w.r.t "modules2" in this list, I conclude >>> that the usage of modules2 with CVSNT 2.5.x should be deprecated. >> >> Depreciated... or, shock horror, how about being fixed? > >modules2 should theoretically be much more powerful because it works at a >lower level... modules has problems when you do things like update -d because >it only really runs as a layer on top of the standard checkout. > >OTOH for 2.6 I ran into problems with it for the next test release. I'll >reinstate it later but may replace (or augment) it with something even more >powerful (that's really only in the back of my mind at the moment - need to >thrash the idea about a bit first (my post in -dev about it at some point). > >> FWIW, I've used modules2 in a test repository and it works for me (but then >> again I'm doing very very simple stuff with it - just shadowing some >> modules within other modules - no filtering). YMMV. > >It does work but some of the more complex scenarios break down due to the >amount of translation required. 2.6 is much simpler (the virtual FS takes >care of the hard bits) but then there are other problems with that :) I >really need to get down and get that to production quality... > Back by the end of 2005 (maybe longer ago) I tried in vain to get modules2 to work properly and gave up. There were problems always when I tried to define the top level of the module.... It never ever worked for me following the doc guides. As soon as a top level was defined all subsequent defines were lost. I just had a look at the modules2.cpp file history and it seems like revision 18.104.22.168 is what is currently used for the CVSNT_2_0_x branch. This includes the latest builds of 2.5, for example it carries the tag CVSNT_2_5_04_2403. But interestingly rev 1.2 is a merge into TRUNK of 22.214.171.124 and there was some development of modules2 functions in revisions 1.3 - 1.8, which were used in test releases on the 2.5 line (last such tag is on 1.8 and reads CVSNT_2_5_02_1979) even though the particular file was on TRUNK rather than on the branch... Now everything named 2_5 seems to again tag rev 126.96.36.199 on the branch, but of course without all the mods up to rev 1.8 present. So I wander if there was a screwup in the branching when developing CVSNT on the branch such that when some fixes were put in place the file was on TRUNK and these fixes have now been left out because you have checked out the entire source tree again on the proper branch? This woiuld explain the apparent lack of any progress on the modules2 handling since a long time back. As far as I can see (not being a C++ programmer) the major changes between 188.8.131.52 and 1.8 are centered on the handling of the modules2 root definition, so it makes me believe that you might have solved a lot of the problems but it is not reflected on the 2.5 releases because it was done on TRUNK rather than on the branch and it was never back-merged.... I guess that if one wants to test the most recent way modules2 behaves on a 2.5 binary one should install 2.5.02.1979 which includes these modifications..... HTH /Bo (Bo Berglund, developer in Sweden)