On 06/12/17 11:30, Mark Thomas wrote: > On 06/12/17 10:34, Konstantin Kolinko wrote:
<snip/> >> 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. <snip/> > Sounds good. And it can be tested without impacting on any of the > current public repos. I'll try it out and report back. I've tested this with trunk and 8.5.x. and it works well. It is also very quick. Much better than my original plan. We would be able to add the older branches to the existing git mirror of trunk. That would make the process something like: - make svn read-only for trunk, 8.5.x, 8.0.x and 7.0.x - disable svn->git mirroring - make git for trunk read/write (we could switch to github as the master at the same time) - merge in branches for 8.5.x, 8.0.x and 7.0.x - clean-up tags - update CI systems, web pages etc for new locations - move trunk, 8.5.x, 8.0.x and 7.0.x to the archive Before we do this, there are a number of points we should think about. You listed a couple below. There are others on some older threads on this topic. I suggest we write up (I'm happy to start it) a list of potential issues and solutions on the wiki and make sure we are happy with those solutions before we migrate. Mark > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
