Florian Achleitner wrote:
> Two approaches:
> 1. Import linearly and split later:
> One idea is to import from svn linearly, i.e. one revision on top of it's
> predecessor, like now, and detect and split branches afterwards. The svn
> metadata is stored in git notes, so the required information would be
> + allows recovery, because the linear history is always here.
> + it's easier to peek around in the git history than in the svn dump during
> import to do the branch detection.
> - requires creation of new commits in the branch detection stage.
> - this results in double commits and awkward history, linear vs. branched.
I don't think you've captured the real pros and cons here.
+ Divides responsibility between a component that fetches and a component
that splits branches, making for easier debugging, independent refactoring
of components, reuse in other contexts (e.g., splitting out branches in
other similar VCSen, etc)
- Divides responsibility between a component that fetches and a component
that splits branches, which is tricky because it involves designing an
interface between them and documenting it. And maybe a different
interface would be better.
There are also performance and history-clarity ramifications as you've
mentioned, but they do not seem as important.
Hope that helps,
> 2. Split during import:
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html