2017-12-05 23:03 GMT+03:00 Mark Thomas <ma...@apache.org>: > Hi all, > > I've been doing some experiments to see how we might migrate from our > current svn structure to git. It appears that git svn is able to follow > directory moves so, with that in mind, I'd like to propose the following > outline plan: > > Plan A > ====== > > 0. Run plan past infra > 1. Restructure svn > 2. Get infra to re-mirror new structure > 3. Validate mirror > 4. Pick a date to switch > > This assumes that we do want to switch to git. My sense from the most > recent discussion was that we did.
I do not want such migration, and am ready to vote -1 here. I postpone my vote to discuss the technical issues (in case such migration ever happens). > To expand on the point one, the restructuring would look like: > > /trunk -> no change > /tags/TOMCAT_9* -> tags/tc9.0.x/ > /tc8.5.x/trunk -> branches/tc8.5.x > /tc8.5.x/tags/* -> tags/tc8.5.x/ > /tc8.0.x/trunk -> branches/tc8.0.x > /tc8.0.x/tags/* -> tags/tc8.0.x/ > /tc7.0.x/trunk -> branches/tc7.0.x > /tc7.0.x/tags/* -> tags/tc7.0.x/ > > and then migrate /trunk, /tags and /branches to git, leaving the rest in > place. Most will stay there. Some components may move to git in the future. Why? When one does a git -> svn migrartion, the migration generally goes up the history of the directory, finds the root revision and starts replicating from there. All those renames will be reflected in history along with the old paths. The new paths do not matter. Those names do not matter for Git. They may matter for future move of svn tree to "archived" directory (the general rule is that the svn tree is moved after committers switch to Git). If the goal is to create a single Git repository from our several ones, my suggestion is to create a repository and pull in the branches from the existing 7/8/8.5/9 git mirrors. Suppose that the repository is configured with origin = URL of this new repository origin-tomcat70 = URL of tomcat70 repository (https://github.com/apache/tomcat70 or better the original one: https://git.apache.org/tomcat70.git) origin-tomcat80 = URL of tomcat80 repository origin-tomcat85 = URL of tomcat85 repository origin-tomcat90 = URL of tomcat90 repository You will get refs/remote/origin-tomcat70/... refs/remote/origin-tomcat80/... refs/remote/origin-tomcat85/... refs/remote/origin-tomcat90/... Now, create local names for those branches (in refs/heads), with "git branch" [--force] or with "git update-ref". (A question is what those local names will be. TBD. My guess that the "trunk" branches will become refs/heads/master refs/heads/tomcat90 refs/heads/tomcat85 etc.) The benefit is that those refs will have the same sha1 as the refs in the the original https://git.apache.org/tomcat[nn].git repositories, allowing to deprecate tomcat[nn] repositories without loosing their history. It also allows us to get the single repository and continue with svn->git mirroring, The structure of repositories svn --[svn-git]--> tomcat[nn].git repositories --[the mapping described here]--> single tomcat.git repository. Though: 1. Current Git mirrors do not reflect edits to svn:log messages (done to correct typos, empty messages, or to add CVE numbers) If we want to keep the corrected log messages, we will need to repeat svn->git migration, but this will invalidate the current tomcat[nn] git repositories. 2. Some git operations do not work with empty log messages. A good time to fill in all such messages in svn repository is before doing re-migration. (I know of "git rebase" having such problem. Generally git has a command-line flag to tolerate such revisions, but when rebase is done with a GUI there is no such checkbox) 3. I wonder what will be the size of such combined repository. BTW, there exist such tool for repository mirroring, but I have not investigated further (I just saw it listed at https://github.com/google/guava/wiki/FriendsOfGuava as the tool used to mirror guava repository) https://github.com/google/MOE > Plan B > ====== > > Pick a different component (native, jk) and migrate that first. > > > If we do want to migrate there will be lots of details to work out such > as how to migrate the "view differences" feature of the migration page > but I'm sure we'll be able to work something out. tomcat-native uses svn:externals link to Tomcat source tree and has a step in release script that checks that this svn:external is up-to-date. All that needs a replacement. mod_jk is OK, does not have such dependency, if I remember correctly. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
