Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E414C7D.1050005@apache.org>
References: <4E3D8D34.8030203@kippdata.de>
	<4E3D91B8.102@apache.org>
	<CABzHfVmd8jd_pd=EmNu5AviRmFGKDxtPELxP1cEQ_-Kyc2Q-bQ@mail.gmail.com>
	<4E3FD2E2.7000002@apache.org>
	<CABzHfVnDEKoEc3WM-cMva0RaajnYs_nqXB3RpcfZ8UgNzxMUvQ@mail.gmail.com>
	<4E402EA5.9030403@kippdata.de>
	<4E40F1D8.5060002@apache.org>
	<4E41002E.3050405@kippdata.de>
	<4E4101F6.8040508@apache.org>
	<4E414C7D.1050005@apache.org>
Date: Tue, 9 Aug 2011 20:42:02 +0400
Message-ID: 
 <CABzHfVnOtw+5uJbZKxq=Pc6c4BfbKcVSzi+E_1_TpFKe4StxFw@mail.gmail.com>
Subject: Re: Replacing tcnative java classes by svn:externals?
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2011/8/9 Mark Thomas <markt@apache.org>:
> On 09/08/2011 10:46, Mark Thomas wrote:
>> 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.
>

Is there a difference between the Java code of native 1.1.x and native
trunk? If there is, one has to keep "1.1.x" sources somewhere.  This
can be decided at a later date though.

BTW, technically, regarding r1155383
--- svn:externals (added)
+-r 1155255 ../../../trunk/modules/jdbc-pool jdbc-pool

1) such externals have to use a peg revision while "-r" in this "new"
syntax specifies operative revision. Thus the syntax with @ below. (@
specifies peg revision, and operative revision is by the fault the
same as the peg one).
2) "../.." will not work when tagging, because "tags/tagname" is two
path segments to be eaten by ".." while current "trunk" is just one.

Thus:
^/tomcat/trunk/modules/jdbc-pool@1155255 jdbc-pool

Documentation:
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html

Second,
I was so enjoyed with Subversion 1.7 that it removes ".svn"
subdirectories from within the working copy. It keeps a single ".svn"
directory in the root of the working copy. With a sparse checkout it
is at a higher level than Eclipse project. It solved some problems,
e.g. Eclipse IDE trying to copy "java/<package>/.svn/**" to the output
folder when compiling Java classes.

With introduction of externals the project in Eclipse now gets an
".svn" directory inside modules/jdbc-pool, because each external is a
"separate working copy" in svn. It would be a bit of nuisance, but I
think it is manageable, because it is not a part of java sources.


With native there will be similar problem: I wouldn't want
/java/org/apache/tomcat/jni/ to be an external,  because that would
bring in "/java/org/apache/tomcat/jni/.svn/**" into the source tree.

Instead it should be some separate project, e.g. "modules/native"
where "java" is a subdirectory inside of it.

It follows that there will be changes in Eclipse project configuration
and in build scripts to take care of the new sources directory.


Best regards,
Konstantin Kolinko

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