Reputation: 79594
TLDR; Due to often sub-standard branching practices on our legacy SVN repository, the history we want to represent as 'master' lives in SVN in a directory which has changed names multiple times. How can I make git-svn trace this history properly?
We have a very old (dating back to 2005) SVN repository, which has seen its fair share of really bad practices in the past. Now we're trying to migrate to git. Naturally, we want to preserve as much meaningful SVN history as is reasonably possible.
Our current work flow ought to map fairly simply to a traditional git workflow. We essentially maintain a permanent 'trunk' branch, along with (typically) two release branches--one of the current release, and one for the upcoming release. New commits get added to trunk (typically after living in a feature branch for a while), then when they are deemed "ready", they get merged to the upcoming release branch (or if it's an appropriate bugfix,also to the current release branch).
So Bug 1234 gets committed to trunk
, then merged to 5.4
(upcoming release branch) and possibly to 5.3
(current release branch). Nothing is ever, on principle, merged directly to 5.4 or 5.4.
Eventually, 5.4 will be released, forked to a 5.5 branch, and work will continue as before.
Bug 3456 will get committed to trunk
, then merged to 5.5
, and possibly to 5.4
. 5.3
at this point is dead.
Mapping this to a common git branching model ought to be fairly straight forward.
5.3
becomes master
, 5.4
becomes develop
, and anything oustanding in trunk
gets moved to a feature branch, to be merged into the new develop
(old 5.4
) as soon as it's ready.
However, things get complicated in our SVN history, becuase we didn't always use this workflow.
We used to commit everything to trunk, then occasionally branch off to do stabilization work for a release.
Bug 1234 would have been committed to trunk, then later, eventually, trunk would be forked to 5.4. Stablization work would be done on 5.4, and merged back into trunk. Eventually 5.4 would be 'released'.
What all this means is that what ought to be considered 'master' and 'develop' have changed in our SVN history.
The current name of what ought to become 'master' is '5.4'. A few months ago it was called '5.3', and before that, '5.2', and before that, 'trunk'.
Is there any way to migrate this SVN history (ignoring tags and branches for now), following back the various renames of 'master'?
A brief history of the relevant renames/branches, in reverse chronological order:
dc/5.3/
is the directory that ought to become 'master'dc/5.2/
was branched to dc/5.3/
; Prior to this commit, dc/5.2's history ought to be reflected in 'master'dc/trunk/
was branched to dc/5.2/
; Prior to this commit, dc/trunk's history ought to be reflected in 'master'trunk/
was renamed to dc/trunk/
; Prior to this commit, trunk's history ought to be reflected in 'master'Upvotes: 0
Views: 43
Reputation: 52679
Easiest way is to dump the repo, filter the offending names so they are returned to 'trunk', and then import it.
You could also just dump out relevant revisions and import those into a new repo, keeping some history for the branches and tags without all the individual commits in-between. Generally I don't think you'll miss the ancient commits.
Upvotes: 1