#1, make sure you have a bug open and a design document (examples<http://dev.chromium.org/developers/design-documents>). Nothing's worse than going off on a long-lived feature expedition and then returning to trunk to find out people don't want the feature or want some other design. #2, work on trunk (as pkasting outlined). Put on red slippers, click the heels together and repeat "There's no place like trunk, there's no place like trunk..." We've successfully developed many features behind command line switches, some of which required major surgery. Working on trunk, your code stays fresh, you get more feedback along the way, and you can have your unit tests running on the builders.
A branch is really only useful if you need to collaborate with someone else or _need_ your code to diverge from trunk. --Mark On Tue, Jun 16, 2009 at 21:35, Daniel Cowx <[email protected]> wrote: > > What is the recommended procedure for working on long/big features? > > In the past, I've always created a separate branch and then done all > my work there. I then do regular integrations from trunk into my > branch to ensure that that my branch doesn't drift too far out of sync > with the trunk (i.e. so as to minimize the amount of merge work I have > to do when I'm ready to have my branch-specific changes reviewed and > merged back into the trunk). However, being that chromium is hosted on > a remote SVN server which I have no control over, what is the > recommended way of doing dev? > > I'd really like to be able to do commits of my incremental work, but > without a sep branch to fiddle around with, how can I accomplish this? > > All input and feedback welcome. > > Cheers, > Daniel > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
