[cvsnt] Betr.: CVSNT to CVS
tony.hoyle at march-hare.com
Thu Apr 9 13:53:05 BST 2009
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
> 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