12-07-04 - 2


Another process note about code development - we try to keep everyone in the company basically on the main line in perforce at all times. Letting people go off on branches (or even just not sync for a while), or hold modified files open - all of these have caused us huge problems, because someone will report a problem, and you don't know if that problem is something weird on their box or a real problem on the main line. We also try to make everyone in content wipe their xbox and sync to perforce daily. Before we did these we would have tons of problems where someone would report a bug, we'd have to go investigate it - and hey, they just didn't sync, or they had a bunch of files open for edit, etc.

Coders have a bad habit of holding big change lists open as work in progress for a long time. I try to kill that - check it in, or revert it. Either it goes in the main line or it doesn't belong on your system. We also try to get people to check in often - once a feature is working or crash-free, check it in, even if it's not done, then keep checking in the little improvements. Also, we fire builds after each check-in. If there are problems, I want to find them right away, not the next day when everyone syncs. As always, the goal is to isolate the problem - if one guy checks in, fires a build, uh-oh, it failed, he can fix it real quick before too many coders sync to the broken build. Another little thing that helps here is whenever you are adding files or changing the project, go ahead and add empty files to p4 and put them in the project, and check that in so the project changes are done. Then check the files back out and work on them just as edits.

No comments:

old rants