Ive posted to this list before about my opposing view to workstation driven devlelopment. Its not that I dont think its a good idea, its great if you have the hardware, tools, and portable applications to support it. BUT...
you can still get away with using a shared server! our team (including designers!) currently use SVN controlled sites on a shared platform and its working reasonably well. a few things i would note 1. Education is key. We showed the whole team how to use tortiose svn at a group meeting and the implications of moving folders and then provided simple documentation on how to use the tool. The standard help files are way too programmer centric to be helpful 2. Work Managment. The common critisism of shared dev is that you loose the concurrency of development. this can be overcome by managing work effectivley so that 2 devs arent in the same file at once. I will admit this is non-trival, but yet still acheiveable. 3. its better than nothing! you get the advantages of restoring, comparing, tagging and perhaps even branching with multiple checkouts on the share. What you trade off is the concurrency and isolation of development in workstations vs the instant integration and simpler deployment of shared servers. 4. is it cost effective to build portability into a legacy site just so you can install it easily on a workstation ? Pat On Oct 15, 3:52 pm, Geoff Bowers <[EMAIL PROTECTED]> wrote: > Andrea, > > On Oct 15, 10:04 am, Andrea <[EMAIL PROTECTED]> wrote: > > > any extra ideas/ best practice ???? I guess everyone has sort of > > similar issues.... > > Your best bet is to set up a local application environment for your > designers, and have them commit changes to the repository just like > your developers. It's not really that hard, *even* for designers, to > pick up ;) Trying to eliminate the designers from committing will > generate just as much if not more work for someone else. > > One of the benefits of a good application architecture is the ability > to port the solution to many different environments. The easier it is > to deploy to local development environments, the easier it will become > to deploy to production. > > At the risk of a gross self-promotion, you might find the following > blog posts useful: > > Working on a Shared Development Server is > Badhttp://blog.daemon.com.au/go/blog-post/working-on-a-shared-developmen... > > Decentralised Development Approach & Version > Controlhttp://blog.daemon.com.au/go/blog-post/decentralised-development-appr... > > Moving to a Version Controlled Build > Processhttp://blog.daemon.com.au/go/blog-post/moving-to-a-version-controlled... > > Subversion: Sorting Out Your Module > Structurehttp://blog.daemon.com.au/go/blog-post/subversion-sorting-out-your-mo... > > Taming the Code at Web On the > Pistehttp://blog.daemon.com.au/go/blog-post/taming-the-code-at-web-on-the-... > > Been working on a much larger series of posts in this area, so if you > have anything that strikes your fancy please feel free to comment. > > Hope that helps, > > -- geoffhttp://www.daemon.com.au/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
