[cvsnt] Betr.: CVSNT to CVS

Tony Hoyle tony.hoyle at march-hare.com
Thu Apr 9 13:53:05 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.

Andreas Krey 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.

It's a revision control system, which is integral part of the wider 
topic of configuration management.  Putting released binaries under 
revision control is a perfectly valid part of that.  Even cvsnt has a 
module for precompiled external binaries - it makes no sense to put them 
anywhere else... the repository is the single source of everything 
required to build a new release, as it should be.

If you need to be able to reconstruct the *exact* build environment for 
an old revision, to fix a bug for a customer, then having the dependent 
libraries in there and possibly even the compilers is a normal thing to 
do.  Not all environments need this but for those that do need it you 
have to be able to support it.

> Let alone in the same repository. Also projects that do this are
> usually not those you can easily contribute to, if at all.

If you're employed to work on a project how easy it is doesn't enter 
into it.

> noticing. It's not just the work but also that you don't immediately
> appear in the global branch name space.

Which means it isn't logged/audited, or backed up on the central server. 
  That is not a good thing.


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