On 4/13/05, RADEMAKERS Tanguy <[EMAIL PROTECTED]> wrote: > - set up one dev server > - set up one source control server > - check the code from the source control server out onto the development > server. > - everyone works on the same dev server. yes, you will need to take care > that two people don't edit the same file at the same time. a neat trick > i like to use is to say "bob, i'm editing file x so keep your grubby > little paws off it!" or to ask "bob, charlie, can i edit file y?".
As noted, this really doesn't work very well and certainly doesn't scale. > - (optional) setup a little script on the dev server to check in the > code. schedule this script to run every x hours. This also can lead to pain. You are better off only checking in code that isn't broken. Or using a branch for bleeding edge code development checkins and then merging back to the trunk when the code is stable again. > - whenever you are happy with the code (it is in a known state), do a > manual check in and apply a tag. Tags should really be used for releases, not just 'known state'. Having said that, automatically tagging the code base with a daily identifier can be useful to restore the system back to a point in time. > Note that, to the best of my understanding, dream weaver has a > rudimentary mechanism for locking files (based on some sort of temp file > created on the server) - but that only works if everyone uses dream > weaver. Also to the best of my understanding, VSS can be set up to > provide protected editing (editing user locks the file) of a web site - > but that only works if every one has a vss aware editor. Correct on both points. > - set up one dev server > - set up one source control server > - check the code from the source control server out onto the development > server. > - everyone checks out the code on their own machine. After every edit, > the developer checks the code in. I definitely wouldn't recommend checking in every change, only working chunks of changes. > - setup a little script on the server to update its copy with the latest > copy in source control. Not worth doing it frequently. You might as well allow developers to FTP to the shared server for testing their changes with other people's code. A nightly build to the shared server should be sufficient. > This way, one developer can't overwrite another's edits. But imagine > this: if you want to change border="0" to border="1" (just to grok a > table), you have to: > - check out the code > - edit (one friggin character) > - check in the code > - wait for the web server to update its copy That's why you have a LOCAL dev env - so you can test it LOCALLY instead of on the shared server! -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:202697 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
