As you can see from the svn commit spam, I went with a variant of b). Initially doing some large commits for files that hadn't had much change on the branch, and then doing a per file commit with additional logging for the specific changes. Apologies for the spam, but I think it'll be worth it in the long term.
Also should mean that JIRA will pick up the merge for each issue too. On Sun, Sep 13, 2009 at 5:38 PM, Henri Yandell <flame...@gmail.com> wrote: > Side thought if anyone feels like having an opinion. > > Which is better? > > a) One big commit, merging the branch in in one go (the usual approach). > b) One commit per file, with the commit log including all of the > change history of the file while it was on the branch; except for a > few global commits that wouldn't add any value. > > One potential bad for b) would be if files were renamed, but that > didn't notably happen in this case. > > It seems a shame to lose history like: > > "r555925 | skestle | 2007-07-13 03:39:24 -0700 (Fri, 13 Jul 2007) | 2 lines > > Added Edwin Tellman's patch for COLLECTIONS-243. > It all seems pretty reasonable, and it should all be checked again as > the project is worked through" > > so I'm willing to give scripting b) a shot. > > Hen > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
