I guess storing the latest version does limit the file size issue, but I am still not sure about some of the other issues that you might have with file references.
How do you deal with different builds? Do you force developers to reference the contents of that folder regardless of whether they are doing a debug build and the folder contents are release build (or worse the other way around)? We use the slap round the head method for breaking builds too, and I agree it works wonders (much better than sourcesafe :)) James -----Original Message----- From: Paul Stevens [mailto:[EMAIL PROTECTED] Sent: 11 August 2004 11:04 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Large solutions and references Sure but we do something very similar here as well, in fact our daily build script goes to the extant of checking all the files out of SourceSafe, building the entire solution, and when it is finished checking the new build into SourceSafe. Since the build folder is set to not keep a history it always only contains the latest build, if a build fails the script does an undo checkout on the files so that development does not come to a stop, and the person responsible gets a good slap behind the head (Works wonders, we almost never have a failed build). Our solution is rather large in total about 200,000 lines of code yet with pdb files and many resource files included it has never reached more than 43MB, a pretty trivial size, This way the latest build is always available to the developer by simply doing a get latest version in SourceSafe in that folder. -----Original Message----- From: James Geall [mailto:[EMAIL PROTECTED] Sent: 11 August 2004 11:21 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Large solutions and references The issue is that sourcesafe has problems once it gets over 4Gb in size. I assumed that the solution size here was large enough to potentially make this a factor. Also if you have satellite resource assemblies these can get quite big very quickly, so keeping one uncompiled file in them is bad enough, let alone all the compiled copies. Currently (because our previous projects were run with the binaries in sourcesafe) the longest part of my day is actually waiting for sourcesafe because it is approaching this size. Don't forget the original question also covered using the same build script on demand as well. This is why we build the solutions on the developer machines as part of a nightly build (actually they are built on a build machine and pushed to the developer machines using a build script that copies them over (if the previous build was successful). Frans, the sourcesafe nightmare is actually ok if you add your projects to solutions as follows: Top Level Sublevel 1 Sublevel2 It only becomes a nightmare if you try and start with adding them in sourcesafe from the bottom (or anywhere else). Source safe info is oddly stored in both the solution and project files and all the project needs is the top level solution. Right in the top of the project file is a reference to the top level solution for source control. Our directory structure is currently CompanyNamespace\Subsystem The overarching solution sits in the CompanyNamespace directory. HTH James -----Original Message----- From: Paul Stevens [mailto:[EMAIL PROTECTED] Sent: 11 August 2004 09:31 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Large solutions and references so based on a working month approx of approx 20 days you will after 5 months have accumulates a terrible 500MB, on say a 160GB (a pretty average size drive these days) drive, I fail to see the big issue, it's not as-if you would get the latest version of every build ever done when you simply want to reference the latest build in your solution -----Original Message----- From: Frans Bouma [mailto:[EMAIL PROTECTED] Sent: 11 August 2004 10:15 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Large solutions and references > Also a nice way to share the base build if you are using > SourceSafe is to check the built dll's into SourceSafe, and > use shadow folders by referencing the files in the shadow > folder, it's very easy to update your local build to the > newest version of the built files by simply getting the > latest version of the build folder from SourceSafe But if the destination dll is huge (and we're talking a huge solution here, so chances are, it is), say 5MB or more, every build will thus use 5MB of space (maybe more) in sourcesafe, as sourcesafe stores a bin file completely. So doing 100 nightly builds causes 500MB of size in your db. :) Not a pleasant thought ;) FB =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com **************************************************************************** ********************************************** Everything in this e-mail and attachments relating to the official business of MultiChoice Africa is proprietary to the company. Any view or opinion expressed in this message may be the view of the individual and should not automatically be ascribed to the company. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and destroy the original message. **************************************************************************** ********************************************** =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com **************************************************************************** ********************************************** Everything in this e-mail and attachments relating to the official business of MultiChoice Africa is proprietary to the company. Any view or opinion expressed in this message may be the view of the individual and should not automatically be ascribed to the company. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and destroy the original message. **************************************************************************** ********************************************** =================================== This list is hosted by DevelopMentor(r) http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
