- Need versioning/backup of files in various states of editing.
- Team members should be able to get the latest build and have it function enough to work on their own part - Not sure the latest version of code checked in by developers should be considered in a "ready to ship" state unless your customers are the beta tester. There are of branching/merging strategies where each developer has a branch and merged but nothing gets to the top build without going through QA. I'll go ahead and throw in Joel Spolsky's $.02<http://search.fogcreek.com/search?q=break+build&btnG=Search&site=default_collection&client=default_frontend&proxystylesheet=default_frontend&output=xml_no_dtd> On 2/8/07, Sammy Larbi <[EMAIL PROTECTED]> wrote:
Tom Chiverton wrote, On 2/8/2007 10:31 AM: > On Thursday 08 Feb 2007, Sammy Larbi wrote: > >>> You shouldn't get hung up on always having a working HEAD. >>> >> Why do you say that? I've always been taught not to break builds when >> you check-in code. Wouldn't that require being hung up on that? >> > > Who cares if HEAD is broken ? > Not the real web site, because that's on a locked down branch, right ? > Not the QA/test site, because that's running against a tag, no ? > So it's only you and your fellow developers. If you have some massive, > going-to-take-weeks change to make, but still want to check in at internal > checkpoints in case your hard disk catches fire, you should be on a branch. > If you are hacking at the one file that has a problem, a quick IM or shout > around the room should be all that is needed to make sure no one else is > goind to update to the 'funny' revision. The only time other dev. members > should be running an update is if they are working on a file after someone > else has done with it. > > What if I want to be able to ship/go live at _any_ time? I cannot do that with broken code (I'll have to revert to the last known good state, but who can tell when that was if we don't concern ourselves with having working code in the repository). As far as the hassle it causes developers, you could IM (or shout) to everyone not to check out the latest code, assuming everyone is willing and able to comply with your wish, and not be affected work-wise. They have the latest just-before you committed, then someone else checks in bad code and possibly leaves for the day, then another, now yours is fixed, but someone else's isn't so someone else still can't check out the latest, and so on. I don't see (yet?) why it should be so hard to not check in bad code, or what reasons you might have for wanting to do so. Even in the case you mention, where you might be hacking at one file for some short time, what is the problem with making sure it works before you commit? I'd just rather not check in broken code. It doesn't seem like a sound practice. -Sam You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
