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.
Today I had a long discussion with one of my developers on the use of virtual modules defined in the modules file. It turns out that he had created a virtual module definition that will check out files from several different server side folders into the same client side sandbox folder. The amazing thing is that the checkout actually suceeds even though in the final sandbox folder files are coming from different folders on the server. Of course it all breaks down after this and that was the reason he turned to me to check what he was doing. It's too long to tell here, just consider his wish a valid one for the moment. So my question or maybe a RFE is this: Can one create a module that can handle this situation in some way, maybe by using the modules2 system? One of the reasons he gave was that the exe he was building required certain dll:s and other common files to be in the same dir as the exe in order for the exe to work. That is why he created the strange definition. When I look in the admin files in the CVS folder I see the following: Root defines which protocol, server and repository is used Repository defines which module on the server the files come from Entries lists the checked out files and their revisions etc Of course if Repository (a real misnomer!) holds the physical module on the server for the directory then of course there can be no mixes. But could one not do the following: Modify the Entries file (or the Entries.Extra) to hold the name of the file *and* the physical server side path to it. Then updates need only bother with Root and Entries.Extra to know where to turn to on the server. And one could handle the case where several files from different server folders wind up in the same client folder. Another observation: When a virtual module is checked out there is no info stored about this so it is not possible to update with this info in mind. Therefore changes to the virtual module definition will not be reflected in the sandbox unless a new checkout is done. With physical modules this is not the case of course. Is there any way to solve this (modules2 for instance)? /Bo (Bo Berglund, developer in Sweden)