On Thu, Jan 28, 2010 at 6:08 AM, Grant Ingersoll <gsing...@apache.org>wrote:
> > On Jan 28, 2010, at 12:13 AM, Jake Mannix wrote: > > > What do you do when your "svn stat | wc -l" returns "66", and you have > fixes > > for 6 of your 7 open bugs? I'd like to check in, but I've also done some > > local rearranging: > > Hmmm, my brain can usually only handle one or two fixes at a time! FWIW, > though, I usually keep separate checkouts or just do one at a time otherwise > you can end up w/ a whole mess of interlinked changes. That's what I've done in the past too - I have currently 15 trunk-with-patch-foo checkouts, and that turned into a bit of a mess too. But at least last night, the issue was that in doing vector perf work, as soon as I stepped a broken unit test through the debugger, I tracked down maybe 4 new bugs, and I knew I'd lose them if I made separate checkouts for each one. > (This is one of the major reasons I like using Maven: I can simply point > IntelliJ at the fresh checkout and create a new project with all the right > setup w/o any of the hassle of configuring dependencies, etc.) > Yep, that is very helpful, I do that too. Although still unweildy to keep track of which checkout has which patch applied and which ones have been svn upped more recently than others... > For me, it works best to create patches often and put them up on JIRA and > then to revert my sandbox and start on the next one. > Yeah, I agree with that in principle, actually. I think my OCD, when it sees little bugs in all of my checkouts (each one fixed in one particular other checkout), I forget which bug have been fixed, which ones have not even been reported, and which ones are fixed in a separate checkout. For big changes, I've been trying to learn git better, and that worked really well for my decomposer import - I kept one git repo in one directory, git pull'ed off of git.apache.org all the time into my local trunk, and then spun off a bunch of different local branches which I periodically merged my trunk into, and created patches based off of this repo, posted to JIRA when tests were passing. The nice thing about this is that I only had *one* directory for all of the branches, and by "git branch foo", the local directory would change itself around, and I didn't even need to open a new IntelliJ project - it would pick up the changes for the new branch on the fly (this didn't work too well with eclipse, as you have to remember to tell it to "refresh" the project, and that sometimes takes forever to rebuild etc. - the rebuilding indexes in IntelliJ was far quicker). > If, however, the changes are all related, then the right thing to do, > probably, is to link them in JIRA so that people are aware of the changes. > What if they're not really related, but are in all the same classes and in methods only two or three lines apart (making it really hard to make sure you have patches which don't collide/conflict)? > At any rate, since you've already made the commit, that's fine too! No, I really would want to learn a good technique at playing nice with the repository/the Apache Way/the Mahout Way, while still moving quickly on a) fixing little bugs, and b) making progress on bigger issues workable (even when I see the same little bug UNFIXED while on each bigger issue checkout). I know most of this is my own psychology: combine working in big spurts with OCD annoyance at seeing unfixed issues in the code I'm digging into, and you get my issues. This should hopefully resolve itself as we stabilize, and I see less little unfixed bugs. :) -jake
