On 18/06/2019 12:42, Emmanuel Bourg wrote: > Le 17/06/2019 à 18:56, Mark Thomas a écrit : > >> The complication is the svn:external that picks up the >> org.apache.tomcat.jni package from 9.0.x. Now 9.0.x has moved to git, >> this no longer works. > > Has it been considered to move the org.apache.tomcat.jni package from > tomcat to tomcat-native? Since these Java classes are the counterpart of > the native code, always evolving in sync, it would be sensible to have > them in the same project.
That hasn't been considered for a while but that doesn't stop it being considered now. I don't recall off-hand why this was set up the way it was. Time for some svn archaeology. >> I looked at a workaround using the "GitHub makes itself look like svn" >> but that timed out for the Tomcat repo. I suspect due to size. >> >> I then looked at Git based solutions. sub-modules and sub-trees look to >> be the two options. Of the two, sub-trees looks better: >> - it is more suited to "read-only" importing >> - it doesn't require any additional commands to populate the imported >> code > > What is the workflow to use git subtrees? I googled quickly yesterday > and it didn't seem that simple, but maybe I'm missing something. My > understanding is that the subtree has to be explicitly configured with > non trivial commands after a 'git clone'. The initial setup is done once (I'll do it). After that, it appears to be part of the repo to anyone cloning the repo. There would be a process to update the subtree. Again, that should be transparent to everyone apart from the person doing the update. Making the change above would remove the need for the subtree. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
