Dave, On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher <wave4d...@comcast.net> wrote:
> Hi - > > I may have helpful ideas. Tell me where the Tomcst site repository and > build are located. > The SVN repo for the Tomcat site is at http://svn.apache.org/repos/asf/tomcat/site/ I'm not sure where the build scripts are stored or executed from. Thanks, Igal > > Regards, > Dave > > Sent from my iPhone > > > On Oct 27, 2020, at 12:18 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > > Konstantin, > > > >> On 10/26/20 20:47, Konstantin Kolinko wrote: > >> пт, 2 окт. 2020 г. в 00:09, Mark Thomas <ma...@apache.org>: > >>> > >>> Hi all, > >>> > >>> The topic came up at the BoF session at the end of the Tomcat track of > >>> migrating the website from svn to git. There were strong opinions both > >>> for migrating and for sticking with svn. > >>> > >>> As a middle ground I'd like to propose we ask Infra to create a git > >>> mirror of the svn repo. > >>> > >>> For those who favour git: > >>> The git mirror would be read-only but it would be possible to: > >>> - clone the git mirror > >>> - make changes in git > >>> - use git-svn to commit those changes back to svn > >>> - then the mirror automatically replicates them back to git > >>> > >>> For those who favour svn there would be no change. > >>> > >>> If there is agreement on this approach, I volunteer to contact infra to > >>> get it set up. > >> My proposal at BoF was for a partial mirror. > >> The issue is that > >> 1. I think that this mirror is intended as a tool to collect feedback > >> / patches from random people, and to lower barriers for contribution. > >> 2. The full Tomcat site is large. It includes documentation for all > >> versions of Tomcat, including javadocs. Those pages are changed rarely > >> and are not needed for people who contribute small changes for the > >> site. The source code for those pages is elsewhere. > > > > The question I have to ask, here is: why do we bother putting all those > files in revision-control? The users guide for 4 different versions of > Tomcat is not a problem, but the javadocs are just stupid to store. > > > > Is there some policy we are following by having all those files in > there? Or is it just to make sure that website "publication" is as simple > as "svn checkout"? > > > >> 3. Subversion has easy commands to cope with such large source trees. > >> This feature is called "sparse checkouts". > >> For our site the necessary commands are documented in README.txt. > >> Essentially, it is done with --depth and --set-depth arguments to "svn > >> checkout" and "svn update" commands > >> Speaking about Git, there are huge repositories [1] out there, but I > >> think that the majority of people are not accustomed to them. > >> [1] https://en.wikipedia.org/wiki/Monorepo > >> I see that Git developers recently did some work to make dealing with > >> such repositories simpler, with addition of "git sparse-checkout" > >> command in Git 2.25.0 [2], released in January 2020. > >> [2] > https://github.com/git/git/blob/v2.25.0/Documentation/RelNotes/2.25.0.txt > >> Though I think that support in tools is still lacking. E.g. missing in > >> TortoiseGit. [3] > >> [3] https://gitlab.com/tortoisegit/tortoisegit/issues/1599 > >> If we go with a full Git mirror or with migration to Git, then I think > >> that somebody has to prepare an update to README.txt. > >> If we go with a partial Git mirror, I think it could be named > >> "tomcat-site-dev", reserving the name "tomcat-site" for a full mirror > >> if we ever make one. > >> Ignored paths for git-svn are configured with "--ignore-paths" > >> argument or with "svn-remote.<name>.ignore-paths" configuration > >> option. [4] > >> [4] https://git-scm.com/docs/git-svn > >> Other notes: > >> 4. Release managers use Subversion to publish the binaries. > >> Thus I expect that they are able to update the published documentation > >> with Subversion as well. > >> 5. Publishing the javadocs generates small changes over a large number > >> of files. The script that generates the commit email notes that the > >> diff is huge and trims it all to a small summary. > >> If we ever migrate to Git, I wonder whether a similar script in Git is > >> able to cope with it. > > > > We might also want to consider complicating the website-building process > in order to simplify the repository. Yes, "disk space is cheap" but it's > kind of ridiculous that we have all that derivative content in RCS, > separate from its canonical source. > > > > -chris > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
