Hi, 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 > available. > + 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, Jonathan > 2. Split during import: -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html