Konstantin, On 8/13/12 3:26 PM, Konstantin Kolinko wrote: > Regarding size of a patch: > ============ > It is up to you. You do it in your own name. The lesser the patch the > lesser are chances to screw it. But if you feel that something needs > to be included as well, feel free to include it. > > Ideally, applying a patch should move Tomcat from one consistent state > to other consistent state. > > It is up to you to explain your patch and to persuade people to review > and vote. The size does not matter by itself.
I'm not terribly concerned with the size of a patch, but thanks for your encouragement. > Regarding merges vs. patch: > ============ > I prefer patch rather than merges. Especially if revisions in the > merge overlap with each other and it is hard to see the result. Patch > is also needed if the merge cannot be done cleanly. > > The two main benefits are that > 1) a patch can be reviewed in one go and > 2) can be reliably re-applied when the vote succeeds, even if the > original proposer is absent or busy. > > I had several cases when I was applying a voted-in set of revisions, > but I had to change it on-the-fly (without additional peer review), > because it could not be applied cleanly. It makes me nervous and I > always mention such inconsistencies in my commit comment. Sounds good. > Regarding recording the merge: > ========== > 1. Technically, "svn diff" in current svn version mentions, what > revisions are included in the patch. So if you did a merge, it is > visible in the patch. Right: this is what I was really asking. > 2. The "svn patch" command does not update mergeinfo, but mergeinfo > can be updated explicitly by doing a "svn merge --record-only". Understood. I almost never do 'svn patch' but instead do 'svn merge'. I didn't know that one could perform a record-only merge, but it sounds like that is a little foolish when the actual patch wasn't really merged but instead a different (but semantically similar or identical) patch was committed instead. > 3. I think current Tomcat 6 is too far away from trunk to try to > struggle over completeness of its mergeinfo. If you can maintain > mergeinfo when you do apply a patch, it is good. > If not, or if it is too much of a burden, do not worry. It sounds like it's really up to me whether I want to bother to attempt to keep the mergeinfo in sync. I'll wait to hear from a few others before I decide what to do... I would prefer a loose consensus on this issue before I more forward. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
