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. Tony