2011/8/9 Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
