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.
Tony
_______________________________________________
cvsnt mailing list
[email protected]
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
Upgrade to CVS Suite for more features and support: http://march-hare.com/cvsnt/
