[cvsnt] Betr.: CVSNT to CVS

Bo Berglund bo.berglund at telia.com
Fri Apr 10 00:03:48 BST 2009

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

(Bo Berglund, developer in Sweden)

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook