Re: [Trac] Re: Migrating repository from svn to git: how to update links?
Thank you for a detailed response. 1. Use a conversion tool that parses database entries and replaces >> revisions bases on svn-to-git mapping. Could not find a good tool so far. >> Suggestions are highly appreciated. >> > > I also have not seen a tool up to the task. It wouldn't be too hard to > write one, you just have to identify all of the database columns that hold > wiki content and do a search and replace. Not hard, but potentially time > consuming. > > >> 2. Add _both_ svn and git repositories to the same Trac instance. >> Regrettably, looks like svn would have to be the default (it is the only >> repository now), so all and every new link from now on shall be namespaced >> to the git repository. Probably OK but ugly. Have not tried it yet, even on >> a pet project. Is there a way to rename the default repository and >> automatically update all the links? >> > > Renaming the default repository and updating all refs is effectively the > same work as in (1). > Yes, looks nearly same. So, decided to skip on this. > I don't think it is ugly to add a second repository and retire the old > repository (i.e. set as readonly). That's the simplest approach, and > probably the one I would take. The only downside is that you have to use > the repository name with TracLinks (e.g. [7f3cc50dd/reponame]). > I gave it a try and it seems to be working OK, not too confusing after a bit of trial and error. > I considered that you might be able to effectively have two default > repositories from the viewpoint of the wiki syntax parser. SVN and Git > revisions are generally distinguishable by integer vs 7 or 8 digit hash as > long as your integers are not too large. If you were ambitious you might be > able to override wiki syntax parser methods to dispatch a Git revision to a > default Git repository. I'm not sure this would be any less work than (1), > and you may have to update the plugin with Trac upgrades. > Probably would skip this one as well: it is similar to 1 in the sense that an application has to be written, tested, and even maintained. And I'd have to deal with the fallout if bugs are uncovered some time after the conversion. > > >> 3. Set up a second, new Trac instance for the git repo and use InterTrac >> to cross-link to/from the old one. Probably OK as well, but could be >> confusing. Initially all the tickets would be in the old Trac instance, and >> many wiki discussions there as well, which would motivate to keep adding to >> the old Trac instance (even if by human error) eventually reducing to >> something like option 2 above: links to newer revisions would come from old >> Trac via interlinks. >> > > This seems worse than (1) and (2). The only advantage is having the Git > repository as the default within the Trac instance. > Indeed, almost like 2 but worse. So, today I implemented the solution 2 and so far it looks all right to me. Thanks again, Dmitry -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Migrating repository from svn to git: how to update links?
Other ideas, anyone? Dmitry -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Migrating repository from svn to git: how to update links?
Dima, thanks for the suggestion. Yes, it is an option #4 but with a catch or two. In fact, we used this approach for some time and generally it worked fine, but: - it was pretty easy for a git-aware person to forget that they are actually using svn and start elaborate branching / merging while away - given git superiority in merging, it was tempting and proved to be very easy to break the svn repository in a major way by performing a big merge in git and dcommit-ting the result without specifying mergeinfo manually (--mergeinfo option of git svn). As I mentioned in the original post, we're now "happy with svn-to-git part". Well, the happiness was achieved by re-assembling svn repo from incremental dumps edited manually to fix mergeinfo for all the branches found it lacking (i.e., merged in git svn without mergeinfo), 3-4 branches and tens of commits to be edited. Now, once I've repaired it all, all I can say it is doable but not enjoyable in the slightest. Now the problem is known and would be easier to prevent, but the experience put a big question mark over using git-svn and dcommits. It remains viable if used with care, but I'm trying to see if there are better ways for a (more) complete migration. Cheers, Dmitry On 11 June 2018 at 02:44, Dimitri Maziuk wrote: > On 6/10/2018 12:36 AM, Dmitry Mikhin wrote: > > So far, I have thought about 3 possible approaches: >> > ... > > 4. Leave svn be, tell all devs to use > git svn clone > ... > git commit > git svn dcommit > > I've sometimes ran into errors trying to "squash" multiple git commits > into a single dcommit, and with multiple forks, but for simple workflows > this works fine. YMMV and all that of course. > > Dima > > > -- > You received this message because you are subscribed to the Google Groups > "Trac Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to trac-users+unsubscr...@googlegroups.com. > To post to this group, send email to trac-users@googlegroups.com. > Visit this group at https://groups.google.com/group/trac-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
[Trac] Migrating repository from svn to git: how to update links?
Hi everyone! Thanks for the great bug-tracker, we were using it since pretty early days and found very convenient and powerful. Now to the question: we're in the process of migrating a long-term project from svn to git. The project has its tickets in trac since 2007 or so, with many links and cross-links to revisions, files in specific revisions, lines in files at specific revisions, and whatever else TracLinks are capable of. Now we're happy with the svn-to-git part, but Trac presented another challenge: how do we update all the link information to point to git commit hashes instead of svn revision numbers? A brief search on the Web provided some tools that are not up to the task (e.g., https://github.com/seantis/git-svn-trac - handles only the most basic form of TracLinks). So far, I have thought about 3 possible approaches: 1. Use a conversion tool that parses database entries and replaces revisions bases on svn-to-git mapping. Could not find a good tool so far. Suggestions are highly appreciated. 2. Add _both_ svn and git repositories to the same Trac instance. Regrettably, looks like svn would have to be the default (it is the only repository now), so all and every new link from now on shall be namespaced to the git repository. Probably OK but ugly. Have not tried it yet, even on a pet project. Is there a way to rename the default repository and automatically update all the links? 3. Set up a second, new Trac instance for the git repo and use InterTrac to cross-link to/from the old one. Probably OK as well, but could be confusing. Initially all the tickets would be in the old Trac instance, and many wiki discussions there as well, which would motivate to keep adding to the old Trac instance (even if by human error) eventually reducing to something like option 2 above: links to newer revisions would come from old Trac via interlinks. So, has anyone performed such a transition in the past and what are your recommendations? Best regards, Dmitry -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+unsubscr...@googlegroups.com. To post to this group, send email to trac-users@googlegroups.com. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
