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.
Thanks for the response. > -----Original Message----- > From: John Peacock [mailto:jpeacock at rowman.com] > > If I understand what you are saying, you have a number of > client modules which > depend on a common set of include files. e.g. > > clientA > \includes1 > > clientB > \includes1 > > clientC > \includes1 > \includes2 > > where the include[n] files are mostly readonly, but > occasionally updated for a > given client and the changes are not being brought back into > the repository in a > timely fashion. Yes, that's right. > The important thing to realize is that every subdirectory in > a given sandbox can > come from a complete different module (even from completely different > repositories and different servers). We do use this occasionally, but not as policy. > ... > When you checkout the include file for a given client, you > could immediately > branch those files so that any local changes you made would > be stored in the > repository but on a branch, not HEAD. Then, at some point, > you could merge > those changes to HEAD then push the unified file back out to > each branch. The > merged file would then be automatically updated on the client > sandbox at the > nexe update. But here's the crux: Suppose I work on clientA, and use include1, then "finish" clientA. I delete my sandbox because I'm done. Now, working on clientB and C results in include1 being modified and changed - maybe even in radical ways. ClientA calls back, I recheck out the files... and it doesn't compile because of modifications to include1. Alternately, 3 or 4 developers working on the same program would need to ensure they have the same version (revision?) of the includes. Note that this is simplified for discussion, in use, we're talking about 15 to 20 includes per project. I am less concerned about the branched "include" development than I am about making sure the "include" is the same for everyone on a project, always. I assume that if someone needs to do a field change to an include, then the first thing they should do is move to HEAD and verify that the bug they are working on is fixed. This also means that when this happens, if other code changes are required to deal with the latest version of the include, then so be it - it's already being addressed. A solution might be to tag each include with the Client name, and make sure everyone updates all the includes (ampersand modules) to the tag, and move the tags only when appropriate. That's still a chunk of manual work for any new developer picking up a project - as they'd have to go to each ampersand module and update to the tag. This might be scriptable in DOS, but it may have to be modified for each project. Another Q: If you update a module to a tag that doesn't exist, do you get the HEAD or simply an error? Could this be done once by updating the parent to the appropriate tag (assuming the tag doesn't exist on the parent)? An "ampertag" might define a default tag for an ampersand module to mitigate this. Another issue that has come up from this: In one of the environments we program in (proprietary software for proprietary hardware - Creston's SIMPL Windows: www.crestron.com) The IDE (if you can call it that) only allows all the includes to come from a @#$#% single folder. I was kicking around the idea of creating a server side script that would build the "include" module on a per-Client basis. Hence the question in my last e-mail: Can I use soft or hard links on the server to present the same version controlled file in different modules? The alternative would be to have ampersand modules (as described above) and mitigate the hard-links on the client.