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 sales@march-hare.com.
"Gerhard Fiedler" <lists at connectionbrazil.com> schrieb im Newsbeitrag news:xxtwrkgfk6xn.zhw0dazscbys.dlg at 40tude.net... > Bo Berglund wrote: > >> "Michael Flad" wrote: >>>A virtual setup would look like that: >>> >>>game1module\ >>> \assets >>> \docs >>> \releases >>> \sources >>> >>>internal\ >>> game1module\ >>> contracts\ >>> sales\ >>> >>>sandbox >>> >>>game1module\ >>> \assets >>> \contracts (internal\game1module\contracts) >>> \releases >>> ... > > It possibly would be clearer and less prone to confusion if you set the > sandbox up like > > game1module\ > internal\ > contracts\ > ... > assets\ > releases\ > ... You're right, it was just meant as an example to "visualize" how I'd like to combine a sandbox using different repositories or modules. >> Seems like you are defining your module in different ways, this is >> probably not going to work. The game1module contains different things >> in your description... > > IMO there's a bit a terminology confusion in cvs discussions when talking > about modules. Modules can be repository directories or definition entries > in module(2) files. It's not clear to me what you're talking about here... That was probably my fault - I used it for both in my question, I should have be clearer. I refered to the modules(2) file because I thought what I'd like to do would be almost the same as the entries within that do, but I'd like to do it manually as it seems to be a more easy/maintainable way for my current environmetn. > The way I see it could work (and IIRC I had some constructs along these > lines that did work) is this (using the directory structure as proposed by > me above): > > - Check out external/game1module into sandbox\game1module > - Check out internal/game1module into sandbox\game1module\internal > (overriding the default checkout location) > > An update on sandbox\game1module should update from both repositories just > fine. In fact, any cvs functions in any directory should work just fine > and > as expected. That's exactly what I tried to achieve. > What will not work is to define something in a modules(2) file that does > the checkout from both repositories automatically (because the checkouts > come from two repositories). But this didn't seem to be what you wanted to > do anyway. > > BTW and FWIW, you don't need two repositories. You could use a top level > module Internal that contains the internal stuff (and possibly a top level > module External, even though only one of the two is necessary) and set up > the ACLs once. Gives you (almost) the same separation as two repositories, > with the advantage that you could start using module(2) files once you > think it's worth it. > >> But if what you want to do is check out a hierachy of folders and then >> inside one of them you want to put a folder that actually does not >> physically exist in the repository at that level, then you will have >> some surprises as soon as you start doing updates and such things. >> Checkout usually works just fine but not the following procedures. > > I had exactly this on occasion and never saw a problem. But I also never > used it exhaustively. Thanks for the answers to both of you. At the moment I settled to using one module with ACLs and a few scripts for setting them up. It seemed to be the safest way, in addition I upgraded from 2.0.58 to the newest stable release and got another (to me) major improvement in ACLs. Using 2.0.58 users with restricted rights didn't get the files, but they got empty directories which was an additional reason for not using ACLs, but that seems to be solved completely now. I'm pretty happy with my current setup and in addition, mixing checkouts seems to be ok too, so I may use them for other things in the future. Great product and a very helpful community. Michael