What you call a "common linkage sandbox" is what is usually called a "baseline" in SCM circles. There are lots of ways to manage them.
They can be built automatically on a fixed schedule, or they can be built on demand. They can be populated with "cvs update -d" or with something more sophisticated (e.g. cvs update -d -r LABEL where the label identifies some reviewed change set or source base). There are also other change set management mechanisms such as submit/assemble. Baselines can be accessed by computing paths based on environment variable settings or configuration files or by using a publish/subscribe mechanism such as buildrefs. --- Forwarded mail from [EMAIL PROTECTED] I realize this is probably a pretty basic newbie-type question, but haven'= t seen anything concrete in the FAQs or Google or recent mailing list topics= =2E If there's a good reference, please feel free to redirect me there! Here's the setup I'm looking at using, and was wondering if anybody has insight: ---------------------- A programmer checks out the few files they're working on from the CVS repository, makes changes and compiles against another 'sandbox' where the= latest versions of all includes, libraries, object modules, etc=2E are kep= t, then checks their modified code back into CVS=2E If the programmer were modifying a =2Elib or =2Eobj, the makefiles current= ly used would compile it into that 'common linkage sandbox'=2E Also, while th= eir initial =2Eexes would be compiled and played with in their local working directory, the final compile for system-test-ready would go to the 'common= linkage sandbox' as well=2E ---------------------- What's the best way to keep the 'common linkage sandbox' up to date? Should I just have CVS run a 'cvs update' against the 'common sandbox' eac= h time a checkin is done? Which of the admin files would be the place to patch something like this into? 'verifymsg'? 'commitinfo' seems to be for checks prior to commit - is there one for post-commit I could use for this= ? Should I just create a custom checkin script that includes the extra updat= e? I don't want to have a programmer be required to check the whole system ou= t and recompile all objects before testing their code each time, which is wh= y we need the 'common linkage sandbox'=2E The system has hundreds of files a= nd it is not easy to determine what subsets of files are needed to properly compile each executable due to poor programming practices in the initial development (yes, the programmer could work that out by inspection of the module they're working on, but I'd like to minimize the need for that)=2E = At the moment, going through and fixing that is not feasible=2E Also, I'm try= ing to minimize the chance that when they do their unit test they are either a= ) linking against out-of-date libraries, or b) if it needs to be run in conjunction with another executable/object (i=2Ee=2E almost a system test situation), those items are not out of date=2E It seems this would be a common issue with large projects, so I'm figuring= there is a proper manner that's commonly used to handle it=2E I saw some mention of the 'common sandbox' on the various Google searches I did, but no detailed descriptions of how to keep that up-to-date, etc=2E If I'm blathering, please feel free to request some deblathering clarification from me! --- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
