tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: Migrating to git
Date Wed, 06 Dec 2017 10:34:00 GMT
2017-12-05 23:03 GMT+03:00 Mark Thomas <>:
> 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.


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
( or better the original one:
origin-tomcat80 = URL of tomcat80 repository
origin-tomcat85 = URL of tomcat85 repository
origin-tomcat90 = URL of tomcat90 repository

You will get

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.
My guess that the "trunk" branches will become

The benefit is that those refs will have the same sha1 as the refs in
the the original[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.

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.

there exist such tool for repository mirroring, but I have not
investigated further
(I just saw it listed at as the tool used
to mirror guava repository)

> 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

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:
For additional commands, e-mail:

View raw message