<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello, this is my second email about infrastructure changes. Since I recently performed the import of the Matrix repository from SVN to Git and had some success (and some failures), I have some suggestions. I used git-svn for this, but some points are general. Also, most points are valid regardless of the host (whether it&#39;s GitHub, GitLab, Bitbucket, your own server, etc.).<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- If your repository encompasses multiple projects, consider taking this opportunity to split them into separate Git repositories. Unlike SVN, a Git repository is easy to move around (on your local disk or to a new host), so there&#39;s less reason to one repo for multiple projects.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Use the --authors-file option to map SVN usernames to those of the destination host; e.g., if going to GitHub, map to $<a href="mailto:username@users.noreply.github.com">username@users.noreply.github.com</a> so their personal email is not exposed.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- If your code relies on the presence of empty directories, use --preserve-empty-dirs, as Git doesn&#39;t keep empty directories (the option places a dummy file in each empty dir).<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- If you&#39;re *moving* to Git and not mirroring, look into changing --prefix to avoid ambiguous branch names (the default sets up the SVN repo like a remote repository at origin/, which is also used when cloning from other remotes, I think).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- Use --stdlayout if your SVN repo has the normal branches/, tags/, and trunk/ split (otherwise use -b, -t, and -T to set these separately). It will recreate the repo with Git&#39;s more efficient branching model than creating subdirectories as in SVN.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- After the import (especially when moving and not mirroring), create a tag that points to the last commit from SVN. This is mainly in case you later wish to see the state of the repository before the move.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">- DON&#39;T delete the Git repo you create in this way after it&#39;s pushed somewhere else. It contains metadata, which doesn&#39;t get pushed to the remote, for reconnecting to the SVN repo. If the SVN repo has new commits after the import, you&#39;ll need that metadata to apply them on top of the Git repo (maybe it&#39;s possible without the metadata, but I couldn&#39;t figure it out).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I also have some suggestions for migrating a Trac instance to GitHub Issues, if anyone is dealing with that, but I won&#39;t send a separate email unless people are interested.<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">-Michael Wayne Goodman</div></div>