On 06/12/17 10:34, Konstantin Kolinko wrote: > 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?
Because having tried to perform an svn2git migration with the existing structure takes far too long (when I tried this a few months ago I stopped after around a week of processing) and ends up including a whole bunch of stuff that didn't need to be there. Moving things around first was an attempt to reduce the work required by the migration process. > 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. In my simple local testing, the moving around prior to migration did seem to have the desired effect. The actual Tomcat repository is much more complex. The end result may not be exactly the same. > 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. I have no strong preference for process. It is the end result I am interested in. > 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. Sounds good. And it can be tested without impacting on any of the current public repos. I'll try it out and report back. > 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. We need to decide which way we want to go for that. Given that we won't be able to edit log messages going forwards, I'm leaning towards going with git repos in there current state but I don't feel particularly strongly either way. > 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) My thoughts are broadly the same as for point 1 above. > 3. I wonder what will be the size of such combined repository. I'll let you know... > 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 Are you suggesting we try and keep svn and git running in parallel? That would require support from infra I'm fairly sure we wouldn't get. >> 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. Agreed. > mod_jk is OK, does not have such dependency, if I remember correctly. I don't recall one. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
