Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>At work I use git-svn against a ~170000 revision SVN repo. What I did was use <code>git-svn init</code> + <code>git-svn fetch -r...</code> to limit my initial fetch to a reasonable number of revisions. You must be careful to choose a revision that is actually in the branch you want. Everything is fully functional even with truncated history <em>except</em> <code>git-blame</code>, which obviously attributes all the lines older than your starting rev to the first rev.</p> <p>You can further speed this up with ignore-paths to prune out subtrees that you don't want.</p> <p>You can add more revisions later, but it will be painful. You will have to reset the rev-map (sadly I even wrote <code>git-svn reset</code> and I can't say offhand if it will remove <em>all</em> revisions, so it may be by hand). Then <code>git-svn fetch</code> more revisions and <code>git-filter-branch</code> to reparent your old root to the new tree. That will rewrite every commit but it won't affect the source blobs themselves. You have to do similar surgery when people undertake big reorgs of the svn repo.</p> <p>If you actually need <strong>all</strong> of the revisions (for example for a migration) then you should be looking at some flavor of svn-fast-export + git-fast-import. There may be one that adds rev tags to match git-svn, in which case you could fast-import and then just graft in the svn remote. Even if the existing svn-fast-export options don't have that feature, you can probably add it before your original clone completes!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload