[cvsnt] Project structure in repository as it relates to branching

Bo Berglund bo.berglund at telia.com
Tue Aug 15 22:16:08 BST 2006


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)


More information about the cvsnt mailing list