As the team's git fanatic I feel it's my duty to tell you that git would help with this, but I agree with the commenters who say that your commits must be reviewed.
The way I use it is a single git branch manages the period between "start typing" and "think this is ready for review commit", while a series of interrelated git branches track the larger arc of your feature. Then you can get each branch reviewed and committed separately. As the team's git fanatic I'll throw in that I think git is very useful for managing an interrelated series of changes -- you can, for example, iterate on feedback on change A while still working on dependent change B. But you also need to be decently comfortable with git for that and learning is slow. On Tue, Jun 16, 2009 at 9:35 PM, 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 -~----------~----~----~----~------~----~------~--~---
