tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Replacing tcnative java classes by svn:externals?
Date Tue, 09 Aug 2011 15:04:29 GMT
On 09/08/2011 10:46, Mark Thomas wrote:
> On 09/08/2011 10:38, Rainer Jung wrote:
>> On 09.08.2011 10:37, Mark Thomas wrote:
>>> On 08/08/2011 19:44, Rainer Jung wrote:
>>>> On 08.08.2011 14:29, Konstantin Kolinko wrote:
>>>>> 2011/8/8 Mark Thomas <>:
>>>>>> On 08/08/2011 12:09, Konstantin Kolinko wrote:
>>>>>>> 2011/8/6 Mark Thomas <>:
>>>>>>>> On 06/08/2011 19:51, Rainer Jung wrote:
>>>>>>>>> Anything I have overlooked?
>>>>>>>> Tagging.
>>>>>>>> If you use an external, you have to be very careful creating
tags else
>>>>>>>> the contents of the tag will appear to change over time.
>>>>>>> When tc7.0.x branch is created, what is the plan for jdbc-pool?
>>>>>>> Will it be copied over to the branch as well, or we can use externals
>>>>>>> pointing to trunk here?
>>>>>> I think the best approach would be for 7.0.x to have an external
>>>>>> pointed to trunk but used an explicit revision. That means we have
>>>>>> make a concious decision to update the jdbc-pool in 7.0.x but tagging
>>>>>> will just work. It also means experimental work can go on in trunk
>>>>>> jdbc-pool without 'infecting' 7.0.x.
>>>>> Sounds good.
>>>>> We can use the same approach for tcnative.
>>>> Yes, that's a good start. So we would usually set the external in
>>>> tcnative to some released TC 7 version, and if there's something
>>>> important in the TC 7 branch which is not yet released and should become
>>>> part of the tcnative next release, we can make a special TC 7 tag for that.
>>> I'd actually go the other way and have 7.0.x have an external to native
>>> 1.1.x using the revision associated with the version of native that
>>> 7..0.x is currently configured to use.
>>> 7.0.x trunk would have an external linking to either 1.1.x head or trunk
>>> head.
>>> That way we have one copy of the native code to maintain.
>> Even better :)
> We just need to be careful to end up with the latest versions of everything.

I've been thinking about this some more and how we usually work with
this code. On reflection, I think Rainer is right and trunk should be
the master copy for this code, with changes ported back to 7.0.x, 6.0.x
and 5.5.x as they are now. With that in mind, I think an external from
native (1.1.x and trunk) that points to trunk is the way to go. The
revision number used for the external can be updated as part of the
native release process.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message