tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Back-porting versus brand-new patch
Date Mon, 13 Aug 2012 20:02:46 GMT

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

> 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.


View raw message