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, 09 Apr 2009 13:53:05 +0000, Tony Hoyle wrote: > Andreas Krey wrote: ... > 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. Nowadays you should probably store the VMware image used for the build and hope that the windows licencing doesn't fool you. ... > If you're employed to work on a project how easy it is doesn't enter > into it. This sentence no verb? I meant, projects that do extensive storage of binaries aren't exactly those you would casually take a peek into, let alone via a slow, nonlocal link. Besides, it would really be interesting to see how well git can compress multiple revisions of not-too-dissimilar binaries. (The fact that most installers contain lots of compressed stuff is rather detrimental here.) > >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. It isn't until you decide the stuff is worth of putting into the central. Just like with regular commits. You could get lazy or clandestine, though. Andreas