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 Thu, 9 Apr 2009 14:25:54 +0200, Andreas Krey <a.krey at gmx.de> wrote: >On Thu, 09 Apr 2009 10:00:59 +0000, Tony Hoyle wrote: >... >> A valid and not uncommon model is to keep the resultant binaries in the >> tree for each released version. > >Someone misunderstood '*source* code control system'. And, since by >definition those thingies (released binaries or installers) never change >there isn't really a point to put them under version control. > >Let alone in the same repository. Also projects that do this are >usually not those you can easily contribute to, if at all. > I disagree on the binaries. I couldn't care less about CD contents and installers etc. But actual product binaries: It is notoriously difficult to recreate a binary that was made 4-5 years ago even if you are able to get all the sources from that tag. The reason is that the development environment itself has changed since then and it is no longer capable of making the requested binary. Then along comes a customer with a problem report on the version we released 4-5 years ago and we have to duplicate it to find the cause, or better yet in the source control we see that a later version (1-2 revisions further on) has fixed his particular bug already. So we need to get him the corresponding binary, which we can no longer build.... Hence the need for committing at the very least all binaries that go out the door to customers, lest we should version control our entire development environment of course. Just imagine version controlling Visual Studio installations along with all the ActiveX stuff it uses from Windows itself. That is what I would call a nightmare! So we store exe and dll files in CVSNT. But then we get into the growth problem where the RCS files grow too big. We had to retire the old location of our main application that has been around since our very start of using CVSNT back in 2001 because it simply was too big for decent performance on our Win2003 server. It had grown to about 300 Mb when it was retired. We were forced to create a bin dir and compile into that and put this under VC while CVS removing the old exe (so it will come back as soon as we update to an old tag. This made a *huge* speed difference in many cvs operations on that sandbox! -- /Bo (Bo Berglund, developer in Sweden)