-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Welcome to Boost's transition from Subversion to Modularized Git!
- Modularized Repositories
- Rulesets
- svn2git Instructions
- Open issues
- Continuous Modularization Job
- This issue aside, the entire release branch and trunk are “accounted for” by our rules
- Changes not-yet-accounted-for by our rules end up https://bitbucket.org/boostorg/svn2git-fallback. When this repository is empty, the rulesets are “complete,” in that they intentionally cover every change.
Once rulesets are complete, we will have a vetting period during which Boosters can inspect the history of their projects and make sure they are happy with the results, submitting edits to the rulesets if they wish to make changes. Instructions for running modularization on your own machine (e.g. to test ruleset changes) are available upon request.
Some Subversion merges are represented by diffs, but not by commit ancestry, in the modularized repositories. Getting this exactly right is a tricky business, for the following reasons:
- Subversion didn't always have a way to represent ancestry, so
- in the earliest commits, the only clues to what was merged may be in log comments.
- later commits may have stored ancestry information using the external svnmerge.py tool.
- Where it is represented in Subversion, ancestry is described essentially as a series of cherry-picks. It may not have a perfectly accurate representation in Git, where an ancestor commit brings an entire history along with it.
- When Subversion finally got native ancestry representation in version 1.5, it was semantically equivalent to what is represented by svnmerge.py, but used a different representation.
- Even after version 1.5, Boosters continued to use Subversion in ways that didn't actually record ancestry, e.g. by applying diffs directly to the release branch from the trunk.
The behavior of future Git merges will be correct as long as the very latest merges to or from active branches are represented with ancestry. Therefore, the cost of all other lost ancestry information is low. Since only a few branches are active (probably just trunk and release), we should consider simply adding a parent map to represent the most recent merges between these active branches in each repository.
- We're using bitbucket for this, at least temporarily, because it's able to show multiple branches/merges at once (see, e.g., wave, which we think may be useful for people who want to vet the conversion.