Take the 2-minute tour ×

The project I'm currently working on is using Trac, with SVN integration. It's worked great until now. Now, however, we've taken on some additional developers and we're running into issues with branching and merging. Because of this, I think a move to a distributed version control system is in order.

The problem is that Trac is very closely integrated with the SVN repository. We have tight integration between the tickets and the revision numbers of code changes corresponding to those tickets. In addition we have a support wiki that has a lot of data that helps the tech. support team. Is there a way we can migrate to git or mercurial without losing the benefits of Trac? I've looked at the git plugin for Trac, and I'm unsure of how well it works. Has anyone here used it with a project that's been migrated from SVN?

EDIT: I should note that the most important priority for us is maintaining the links between Trac tickets and the corresponding changesets in SVN. That's a tool that we use every day, and it provides an easy way to jump to code changes when reviewing tickets. Wiki migration would be nice to have, but if it's not possible, we can continue to run the old system whilst we write some kind of a one-off script to migrate the content.

share|improve this question
What kind of problems did you have by branching/merging ? Are they really caused by SVN or your branching strategy ? –  khmarbaise Apr 20 '12 at 6:32
I would not risk this on a real industry project. Instead make sure the new developers (and the old ones) know how to use subversion correctly. –  scarfridge Apr 20 '12 at 7:15
@khmarbaise: The mere fact that you have to give your branching/merging strategies that much thought, and that fact that things break in horrible ways when you do it wrong, are signs that something isn't quite as it should be with subversion. –  tdammers Apr 20 '12 at 7:28
I recently tried to migrate a very big project from Trac to Mercurial. We spent a lot of time trying each piece of tutorial we found online and tool that were suggested. Everything failed. –  user2567 Apr 20 '12 at 10:16
add comment

2 Answers

I used Trac + SVN for a long time and really liked it. I think that it is a highly competitive solution, and (although I currently use Hg) would think twice about changing.

It might be worthwhile taking a little time to examine what other factors might be causing problems. Look beyond the purely technical and consider team structure and organization, personalities, processes and communications structures.

For example, is it feasible for everybody (as much as is possible) to commit to /trunk instead of branching? Integration problems will be found and fixed much faster if you do this. It also makes it much easier to configure Development Automation tools like Continuous Integration; Automated Test servers etc...

share|improve this answer
add comment

Your first question should be "how do we branch/merge better" rather than "I've heard good things about cool tech x, lets try it". If you really want the latter, then you should be setting up a test/evaluation system and making sure that it not only solves the problems you have, but also doesn't introduce different problems.

So why is svn merging such a problem for you? I hope you're running a later version (1.5+) as I've seen companies sticking with 1.3 for years.

Merging in SVN does work, its not broken, so what are the problems your new developers (I assume the old ones are working with it fine....) are having. They need to be educated in how to use the system better. We all know any system can be broken by "stupid users", are these guys checking in by simply overwriting conflicts with their code? Are they failing to merge with the right option? Do you have reintegration merging set up and are they not closing their old branches after a reintegrate?

share|improve this answer
The problem is that we no longer have a single "mainline" product. The product itself has branched into multiple versions that are customized for our resellers. As I understand it, this situation (multiple related branches, all of them equal) is not one that is very well supported by SVN. My evidence for this is that every merge between branches has taken hours longer than expected, with lots of tree conflicts and careful manual merging. –  quanticle Sep 6 '12 at 16:43
In addition, we're also planning to eventually cross license our code to another company overseas. Unfortunately, the bandwidth between our sites isn't great, and so it'd be nice if they had a repository of the code that they could work on locally, without needing access to our servers all the time. –  quanticle Sep 6 '12 at 16:45
add comment

Your Answer


