tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Replacing tcnative java classes by svn:externals?
Date Tue, 09 Aug 2011 09:46:30 GMT
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 <markt@apache.org>:
>>>>> On 08/08/2011 12:09, Konstantin Kolinko wrote:
>>>>>> 2011/8/6 Mark Thomas <markt@apache.org>:
>>>>>>> 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 that
>>>>> pointed to trunk but used an explicit revision. That means we have to
>>>>> 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 for
>>>>> 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.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message