DragonDisciple
commented
5 years ago This is more or less a concept that I hacked together after comprehending what the functions were doing. I didn't make any great attempt to refactor or simplify the data structures. It works for our team's repository, and has successfully migrated it to the monorepo. If you see no issues with it, we can get it merged in.
The key things that I'm curious about changing after understanding more is the change to a list for base_svn_revisions object. It seems dirty how I hacked in the changes to it, and would be amenable to updating it if I get more assumptions I can go by through understanding more about the monorepo conversion.
I had 2 assumptions I made during development:
- Old git commits have a 1-to-1 mapping to svn revisions
- Monorepo revisions never have subproject information
I tested these and they came back true across the board (https://github.com/DragonDisciple/llvm-git-migration/commit/39885b0396a74825b0eea51bdba4f1871d3553eb)
Commit 2f2aeb9b has the following in its log:
llvm-svn: 181277 llvm-svn: 181274 llvm-svn: 181273
I assume this is because it is a commit that exists in 3 subprojects, and thus has 3 separate svn revisions which were combined during monorepo conversion.
find_svnrev assumes a 1-to-1 git commit to svn revision correspondance which seems inaccurate with how the monorepo is now laid out.
This commit now has the function return a list of tuples, so that we can represent the 1-to-many git commit to svn revision relationship.
This also required a change to the regex, which used '\Z' to match the assumed 1-to-1 svn revision associated with the commit. This assumption is no longer true in the monorepo. The new strategy is to start at the end of the message and work our way up, matching each line as an svn revision until we reach the first non-match.
Fixes #18