<div dir="ltr"><div>As we all know, svn2git migration is pretty trivial. However, to achieve the full power of being within the GH community, having our tickets also in GH is important. It's also hard to do.</div><div><br></div>So, I've burned the better part of several days prototyping this, since none of the "as built" scripts lying around the internets did everything we wanted, and GH technology has improved since many of them were built. As I saw it, the migration should<div><br></div><div>- convert r1234 references to hash references</div><div>- convert #1234 ticket references correctly (just ensuring 1:1 ticket # equivalence achieves this)</div><div>- convert trac markup as much as possible into markdown</div><div>- retain as much metadata (milestones, priorities, components) as make sense</div><div><br></div><div>Some issues come up right away:</div><div><br></div><div>- GH issues just have labels, so a complete mapping of all trac attributes can result in very noisy tickets. Some culling of "defaults" makes sense, but that's easy enough. </div><div>  - Milestones are handled separately in GH, so that attribute moves across cleanly.</div><div>  - Resolution types, components, priorities have to become labels. Color can be used to inform "typology". </div><div>  - All this ends up being editorial choices, not impossible at all.</div><div>- GH API won't let you create new objects on behalf of someone else. Net effect being, all migrated issues and comments end up owned by the creating entity. Of course, once migration is done, ownership of new things is correctly handled. You can see the effect of this in the mapserver migration: <a href="https://github.com/mapserver/mapserver/issues/2154">https://github.com/mapserver/mapserver/issues/2154</a></div><div>- New beta GH Issue Import API does allow issues/comments to be "back-dated", so a comment from 2012 will have a 2012 date. This is very nice.</div><div>- Issue API in general won't allow tickets to be assigned to folks who aren't in the organization of the repo being worked on. For my example imports, this resulted in no ticket assignment. For a real migration, this would limit our ability to assign to just folks in our postgis organization.</div><div>- The new beta GH Issue Import API didn't seem to like my milestones, for reasons currently being looked into.</div><div><br></div><div>Long and short of it, since folks are basically saying "never never never", I am demotivated to complete the investigation and get the "most perfect" migration I can to show you all what it would look like. I have a migration that is slightly better than the mapserver one (dates are correct on tickets, and all the revision references are remapped to hash references) but if there's no enthusiasm for getting into that larger pool, I'm going to stop swimming and return to other, more useful work for my employer.</div><div><br>P.</div></div>