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.
On Mon, 23 Jan 2006 22:20:12 +0100, "Michael Flad" <MichaelFlad at web.de> wrote: >Hi all, > >is it ok to checkout modules/submodules into a sandbox of any other module? >I've done some tests and it seems ot work but before I start using such >a setup in a production environment I'd better backup that by someone else' >knowledge. > >Some more infos to better explain why I want to use it that way > >I have a growing number of different software projects I'm working on >with a business partner as well as with some external companys/freelancers. > >In general I like to have as much project related stuff within the project >folder as possible, this includes typically "public" stuff like art-assets, >source code, master/release builds, documentation but also internal infos >like contracts, sales results etc. only meant to be viewed/changed by my >bussines partner. It may be also some core technology I do not want to >share with contractors or whatever (so the public part would f.i. only >contain a library but not it's sources). > >It would be possible to handle these conditions with ACLs but that would >be more work to maintain and have to be done again for each new project. >By using one internal repository with modules containing only internal >subdirs I only have to tell my partner once how to handle/checkout it >and we're done "forever". > >Using modules/2 would be another possibility, but I aim at the most simple >and flexible solution with as little adminwork as possible (as I'm already >work-overloaded :-)) I guess behind the scenes what I like to do is >probably the same as using a modules file? > >A virtual setup would look like that: > >game1module\ > \assets > \docs > \releases > \sources > >internal\ > game1module\ > contracts\ > sales\ > >sandbox > >game1module\ > \assets > \contracts (internal\game1module\contracts) > \releases > ... > > >Thanks in advance for any responses and best regards, 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... Before we starterd using the modules file I experimented with having a batch file in my main source dir and the instructions were to execute this batch file *once only* in place. That would check out stuff to places below the project folder. It worked but there were glitches here and there, especially if I wanted to shorten the path to one or two subdirs... So it all depends, if you have a top level directory (your project dir) into which you collect various checkouts as subdirs of this (empty) dir, then it can be arranged via the modules file using ampersand modules. What will happen is that the top level dir is designadet by CVS as coming from CVSROOT/Emptydir (look in the CVS/Repository file below this dir). Then all of the other dirs are expected to be actual modules in your repåository and they will be all fine. 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. We had a case in this direction when a developer wanted to rearrange code as follows: 1. There are a number of similar "projects" which implement various ways of interacting with some equipment. We keep the sources in separate submodules in our repository below a mast module. 2. In this we also for practical purposes keep a "bin" folder into which all of the projects are supposed to depsoit their compiled binaries. 3. Now the developer wanted to define a module thta would check out his special project and have the bin folder below his sources folder. He also wanted to check out only his own binaries there, so the sandbox would have to be marked Static. This is all doable within the modules file, at least the checkout succeeds and all files are where they are expected to be. 4. But when he did an update on his project, what happened was that all of the files actually in the bin folder were exctracted into hiw sandbox bin folder. For some reason the Static property was being lost. So we had to revert to having the bin folder on top in parallel with the sources folder. That was perfectly all right. There may be other issues as well of course... /Bo (Bo Berglund, developer in Sweden)