On 29/10/2020 19:27, Igal Sapir wrote: > 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.
There is no automated build. Committers run the scripts locally when the site needs updating. Details in the read me file in the root of the repo. Mark > > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
