Re: svn/git for website
On 29/10/2020 19:27, Igal Sapir wrote: > Dave, > > On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher 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 : >>>>> >>>>> 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..ignore-paths" configuration >
Re: svn/git for website
Dave, On Wed, Oct 28, 2020 at 9:36 PM Dave Fisher 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 : > >>> > >>> 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..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 > >
Re: svn/git for website
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 > wrote: > > Konstantin, > >> On 10/26/20 20:47, Konstantin Kolinko wrote: >> пт, 2 окт. 2020 г. в 00:09, Mark Thomas : >>> >>> 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..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
Re: svn/git for website
On Tue, Oct 27, 2020 at 12:17 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Konstantin, > > On 10/26/20 20:47, Konstantin Kolinko wrote: > > пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > >> > >> 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..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. > That makes a lot of sense to me. I'm sure that the whole process can be scripted, including the script that Konstantin mentioned
Re: svn/git for website
Konstantin, On 10/26/20 20:47, Konstantin Kolinko wrote: пт, 2 окт. 2020 г. в 00:09, Mark Thomas : 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..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
Re: svn/git for website
пт, 2 окт. 2020 г. в 00:09, Mark Thomas : > > 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. 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..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. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn/git for website
On Fri, Oct 2, 2020 at 12:09 AM Mark Thomas wrote: > 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. > > Thoughts? > My personal preference is to move to Git! Martin > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
svn/git for website
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. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
