Hi - I may have helpful ideas. Tell me where the Tomcst site repository and build are located.
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
