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 Tue, 15 Aug 2006 17:07:59 -0400, "Nick Duane" <nickdu at msn.com> wrote: > >Along these same lines, I have a thirdParty module that contains thirdParty >code (headers & libs from external sources). My current thinking is that >I'll put this under each and every top level module as opposed to it being a >top level module under the repository. The reason is that if someone >updates any of these I don't want it to affect all modules. Each module >should be able to upgrade to a third party version on their own timetable. > >And in order to confidently be able to say I can reproduce any past release >it seems as if I should also put the development tools and sdk's (VS.NET, >Platform SDK, etc.) under CVS control also. Is this what others do? I don't think it is enough but it depends on what kind of programming you do. For example on Windows there are often common registered files that "plug into" the development IDE and contribute to the final product even though they are not part of the development system or of the product sources. I have deduced that it is impossible to actually get enough into CVS that a complete rebuild with binary equality is possible.... So we store not only our sources in CVS but also all of the binaries we produce that go out the door in any way. Then we can at least retrieve the exact binary in the future. Our Installer tool (InnoSetup) on the other hand is treated like that. We store all the installer scripts in CVS and also InnoSetup itself and we use a batch file to bootstrap exports from CVS when we build our release setups. This includes getting InnoSetup itself from CVS so the build does not need Inno installed to work properly.... HTH /Bo (Bo Berglund, developer in Sweden)