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
