David E Jones wrote: > On Dec 3, 2009, at 11:36 AM, Adam Heath wrote: > >> David E Jones wrote: >>> On Dec 3, 2009, at 5:18 AM, Scott Gray wrote: >>> >>>> On 4/12/2009, at 1:05 AM, Hans Bakker wrote: >>>> >>>>> If you want to review these commits why not check them in the birt >>>>> branch...there they are separated. >>>> I'm not so concerned about myself but more for others and in particular >>>> people looking at the commit history in the future. >>>> The integration and the examples are completely different subject matters >>>> are should be treated as such when committing to the trunk regardless of >>>> how they've been committed to the branch. >>> How would one separate them when committing them to the trunk? >>> >>> Typically merging a branch with the trunk involves a single commit in order >>> to keep it simple. It doesn't have to be that way, but it nice to simply >>> say branch rev X was merged into the trunk at trunk rev Y. >> You may not have noticed, but I've done several bulk commits with >> git+svn. I'll do a whole bunch of work, then when everything is >> finished, and I've doing various testing at each individual point in >> the chain, I'll flood svn with several commits back to back. You'll >> see all the individual, *small* changes, as I first fix bugs, rename >> methods, make things private from public, then finally remove whole >> swaths of code. Look at the UtilCache stuff I did recently, where I >> made the constructor(s) private. > > That's great Adam, but not how branches are generally done. There is already > a revision history in the branch, so why duplicate that in the trunk instead > of doing a more traditional, easy, and clean merge? > > In fact, I like branches better if you want to collaborate with others. If > you don't it doesn't really matter I suppose.
If you consider that I was doing it with git, which is done offline, then my explanation makes sense. Scott's suggestion about keeping *trunk* history nice and neat is a valid point. Git allows that to happen in a much easier fashion. And with git, you can still publish your local changes, it just takes a bit of configuration. Not to mention the fact that you can work *completely* offline, even doing stuff in plains, trains, and automobiles, saving commit history, instead of waiting for a network connection. > > -David >
