2012/8/13 Christopher Schultz <ch...@christopherschultz.net>: > All, > > Recently, I have made a proposal or to to back-port changes into Tomcat > 6. In one case, Konstantin has (helpfully!) provided a new patch based > upon several changes to trunk/TC7. > > In this case, is it more appropriate to apply the single patch to TC6 > and ignore those patches made to trunk, or should I attempt to back-port > as much as possible to keep as much svn:mergeinfo as possible? > Practically, the log messages and changelog should be enough for anyone > interested in the history of the code, but I wanted to be clear at what > point attempts to do an 'svn merge' should be abandoned in favor of a > cleaner patch derived from the originals. >
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. 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. 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. 2. The "svn patch" command does not update mergeinfo, but mergeinfo can be updated explicitly by doing a "svn merge --record-only". 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. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
