Alan D. Cabrera wrote: > Brett Porter wrote, On 11/24/2005 4:23 PM: > >> My thoughts: >> - this is more risky that it will be missed if someone misses one >> >> > This is not as likely if the commits are made to both lines at the same > time.
I don't understand this reasoning. If using this technique, if one is missed, you have to backtrack and find what was missed. If you use the weekly technique (or whatever interval), you are merging everything since last merge ensuring nothing is missed. > Also, there will be times when it will not make sense to apply > the branch change in the trunk. You want the original patch author to > make that investigation and decision at the time of the checkin not a > "third party" branch merger at the time of a branch merge. I don't exactly agree. The only case where I feel something should go onto the branch and not the trunk is if that functionality was removed on the trunk for some reason. In that case, the merge will conflict on that change and it can be easily thrown away. Do you have a specific use case? > >> - its more cumbersome on an individual commit >> >> > Not more cumbersome. Waiting to do the work at the uber merge merely > postpones the inevitable. I can't agree here. Assuming no review, per commit adds a command for every commit, per week adds a command per week. Getting into review stage - you've already said that the review is the same at either point. I'd prefer to do them sequentially myself. I understand that there might be some issues that require the original author to be involved. In this case I'd instead encourage authors to still be aware of the affect of their changes and if they think they will be problematic - to call for an early merge to raise a flag on it. That fits the community style better too :) > Blind merges that just dump whatever is in a > branch into the trunk are always dangerous without careful scrutiny; > performing this due diligence makes it the same, usually more, amount of > work as individual multi branch commits. I agree blind merges are bad. When I do it, I always review the resulting commit to ensure it still makes sense. And aside from that, you rely a lot on your automated testing to ensure everything is still sane. I see where you are going, and it probably becomes more the case as you get to a much larger project size than what we are dealing with (100's of developers instead of 10's). The fact is that the majority of commits in the project at present are comfortably isolated and merge nicely. > And you want to know of the clash and have that discussion asap, at the > time of the checkin, not later. Issues like this need to be resolved > before the trunk evolves further and while things are still fresh in > everyone's mind. That's true. I've thought about Maven tracking last merge points and allowing CI to automatically perform that merge on the trunk automatically and alert when it has a conflict and then let someone resolve that, and then test the build. > The paradigm I espouse applies to what ever product management style > that is in place. The issues that I raise are not as relevant for more > mature product lines that do not change that radically. But it has > always been my experience that a "blind" merge at the end of a branch > release is always more work and error prone than "multi branch" checkins. > > Just my 2 cents. :) That's fair enough, but I just don't see it here where we are doing very little (well, currently no) trunk work. And its super tedious and anything tedious is error prone. I'd grumble about doing it, and anything you have to grumble about is going to cause some sort of issues. Others are welcome to disagree with me :) Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
