begin quoting James G. Sack (jim) as of Wed, May 23, 2007 at 01:21:44AM -0700: [snip] > I add my vote to the prior remarks about SCM.
I'd start with simple centralized version control. Everything else can be built up from that. (Note -- git and hg can 'push' changes from the local repository to a remote one, as well as 'pull' changes down, so you can build a centralized version control system using them, even if they aren't encouraging you to work that way.) > Regarding NAS, requiring/encouraging developers to use common storage > for their work environment makes it possible to implement automatic > backup, I suppose. That's what the version control software is for. Actually, it's why I tend to prefer centralized version control -- check everything you want to keep (as in, can't rebuild automatically) into version control. If you didn't check it in, you shouldn't mind it getting blasted. That being said, it's often useful to give each developer a "scratch" repository for checking in experiments-in-progress, favorite tools, etc., so if they do sit down on a blank machine, they can easily recreate /their/ preferred environment. > And emphasizing the shared environment, one might argue that it could be > easier to develop good (or at least documented) conventions and working > habits -- directory structures, filenaming, ???. Depends on what's being shared. Frequent integration (e.g., daily commits to the version control system) and good developer communication helps with stuff like filenames, directory structure, etc. > Anybody want to add other advantages? .. Disadvantages? Some folks tend to get gung-ho on the idea of "normalizing" everything. They extrapolate from standardizing on the tools used to interact with the other developers to standardizing _all_ of the tools used by everyone. Personally, I think this is counter-productive, stupid, and harmful. > I guess tradition is to have NFS-mounted homedirs, eh? I myself have > never really worked that way. Can others comment on how this works out > in a development environment? BTDT. When the network hiccoughs, work stops. If someone else is in charge of your network -- not the case here, I think -- then *their* "unannounced maintenance event" can cripple everyone for a day, at best, and for a couple of days as you seek out and restore corrupted files, at worst. > Are developers jealous of their private workspace? Depends on the developers. When I've seen the "let's all play in one shared directory" set up, what really tends to happen is that developers copy the things they're working on to where they'd REALLY prefer to work... and then copy 'em back. So... stuff gets stomped on, integration sucks, etc. -- and bad habits get formed. When they *do* get their own workspace, they check the product out of source/version control, copy it, work on it... and *still* stamp on changes that they shouldn't've. It's a dance, balancing developer privacy and developer cooperation; one has to admit that developers are *people*, and not cookie-cutter automata. -- Chocolate chip. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
