Forgot your password?
typodupeerror
Bug Programming Software IT Technology

Best Integrated Issue-Tracker For Subversion? 99

Posted by timothy
from the good-subversives-use-samizdat dept.
JobSeeker writes "Now that subversion has merge tracking my boss wants to save money by dropping our expensive commercial solution. I've pretty much convinced myself that subversion can do the job. I like it. But what about integrated issue tracking? Version control without issue tracking is only half a solution. The TortoiseSVN docs say a little about bugzilla and not much else. What ready-to-play options (commercial or open source) exist for deploying subversion on commercial projects?"
This discussion has been archived. No new comments can be posted.

Best Integrated Issue-Tracker For Subversion?

Comments Filter:
  • trac (Score:5, Informative)

    by bizpile (758055) * on Sunday July 27, 2008 @08:44PM (#24362693) Homepage
    trac [edgewall.org] + subversion works well.
    • Totally agree. Trac is the best. Includes a wiki that is very useful.
      • Re:trac - no ... (Score:4, Informative)

        by Anonymous Coward on Sunday July 27, 2008 @09:18PM (#24362991)

        trac is not the best solution. Trac is a one-install per product gig.. not something that'll allow you to version and actually track issues across multiple products and multiple environments and multiple subversion repositories... all at once.

        Also, the wiki isn't that good.. tons of other great options that are actually good to wiki on.

        Jira has a great subversion connector... Jira has its quirks that I hate.... and I'd choose bugzilla if it weren't for a job.. but, honestly, the few thousand dollars jira is.. completely worth it.

      • Re:trac (Score:4, Insightful)

        by turbidostato (878842) on Sunday July 27, 2008 @11:03PM (#24363699)

        Big problems with trac (to the point to be showstoppers to us):
        1) Support for only one project/product per install
        2) Tickets don't support hierarchies
        3) No real ACLs

        Not that there are no (more or less dirty) workarounds but for us, Trac is "almost there" but still not on target (and so has been for about two years).

        • Re:trac (Score:5, Informative)

          by turbidostato (878842) on Sunday July 27, 2008 @11:18PM (#24363797)

          By the way, there's Redmine that seems trying to be to Trac what Subversion is to CVS (in that it clearly builds up on Trac experiencies trying to do it better). It is multiproject for one, but I really didn't have the time to play with it (what about user management integration with LDAP, ACLs, threaded tickets, mailbox management, etc.).

          That said, Redmine is based on RoR, so I really don't know what will happen when/if they find the limits of the framework (and on my environment it seems easier to find people with Python experience than Ruby). To me and by now, I'd enjoy if Redmine/Trac is the base for a sane competition between them.

          Back on topic, not exactly what it was asked but one of the best open source ticket tracking tools over there I think is OTRS (no SVN integration and Perl based, though).

          • by Lorens (597774)

            not exactly what it was asked but one of the best open source ticket tracking tools over there I think is OTRS (no SVN integration and Perl based, though).

            I use OTRS every day but I dislike the layout. I prefer the interface choices made by RT. The problem is that RT is getting to be a really heavy beast, and the mail->ticket interface could be made to lose tickets :-(

            But it's so very heavy that . . . google . . . yes, a search on RT + subversion returns discussions about integration, things like "if your commit log looks like this:

            RT-Ticket: 23
            RT-Status: resolved

            this is a commit log

            then RT will add the commit log to ticket 23, resolve ticket 23 and make t

          • Re: (Score:1, Informative)

            by Anonymous Coward
            I have been using redmine for over half an year now and I highly recommend it. It does the job and doesn't get in the way. Trac does...
        • Re: (Score:3, Informative)

          by djcapelis (587616)

          There's actually a good plugin for supporting dependencies. We used it on a past project with some success: http://trac-hacks.org/wiki/MasterTicketsPlugin [trac-hacks.org]

        • Re: (Score:3, Informative)

          by Jack9 (11421)

          3) No real ACLs

          To clarify, there are no real ACLs for tickets.

          For ACL to source, you can use SVN perms via trac.ini, authz_module_name if your authz_file contains permissions which are project named. Some people like me, are sometimes found using (Apache) Location directives before figuring this out.

          (authz_file contains)
          [calc:/branches/calc/bug-142]
          harry = rw
          sally = r ...
          (trac.ini contains)
          authz_module_name = calc

          Trac now recognizes ACLs the same as SVN does.

          • Re: (Score:3, Informative)

            by turbidostato (878842)

            "For ACL to source, you can use SVN perms"

            Will this work on searchs or if you trac-link from a wiki page or ticket?

            Regarding ACLs, I'm afraid is an all or nothing bussines. Current status (while I didn't look at 0.11 yet) means we cannot have a "private" section for our developers (yes, I'm aware of the "private" egg, but it doesn't work -shows "private" results on search, for instance), or "private" comments on tickets, etc.

            • by Jack9 (11421)

              Will this work on searchs or if you trac-link from a wiki page or ticket?

              This will prevent someone without adequate perms from accessing a page result, from a search. I don't think it applies to search results per se. It will prevent someone without adequate perms from accessing a page linked from a wiki.

        • 1) wrong [edgewall.org]

          2) wrong [trac-hacks.org]

          3) Okay...now you're not even trying. Real ACLs are actually built into the main trac interface (i.e., roles, users, and linking permissions). They work right of the box.

          Not that there are no (more or less dirty) workarounds

          Look, these plugins just work. I don't know what the problem you have with them is. They're not workarounds - they're the main thing.

          The only thing missing from Trac that I wish I could get easily is integration with active directory for permissions management.

    • Re:trac (Score:5, Informative)

      by liquidpele (663430) on Sunday July 27, 2008 @09:31PM (#24363107) Journal
      I've been looking at this recently actually... and Trac's interface is still something to be desired. Here's my list of decent ones imho:

      Trac - Nice, but interface is a little clumsy.
      Retrospectiva - Nice layout, but really new and not much known about it
      Bugzilla - Nice and lots of support, but the interface makes you want to kill yourself.
      JIRA - The best one, but it's only free for open source products (not me) :(
      • Re:trac (Score:5, Informative)

        by liquidpele (663430) on Sunday July 27, 2008 @09:37PM (#24363143) Journal
        Oh crap, forgot:

        mantis - Decent layout, but features are just a little bit limited. 2nd place in my opinion.

        Also, demos:
        mantis demo [futureware.biz]
        retrospectiva Site (demo) [retrospectiva.org]
        JIRA Demo [jira.com]
        Trac Demo [hosted-projects.com]
        Bugzilla [mozilla.org] - this is mozilla's live bug track, not a demo.
        • Re: (Score:3, Interesting)

          by Myen (734499)

          Bugzilla's demo site is http://landfill.bugzilla.org/ [bugzilla.org] - go ahead and file junk bugs there, nobody would care.

        • at work we are using mantis + svn + hudson, so when we commit we can enter issue number in commit message and then will hudson add a note to the issue in mantis telling what build fixed the issue
      • Re: (Score:3, Informative)

        We use JIRA at work. It costs money for commercial use, but it is really, really nice. Integration with Subversion is available as a plugin [atlassian.com]. The main product is http://www.atlassian.com/software/jira/ [atlassian.com].
      • Bugzilla (Score:5, Funny)

        by Tumbleweed (3706) * on Monday July 28, 2008 @12:09AM (#24364079)

        Bugzilla - Nice and lots of support, but the interface makes you want to kill yourself.

        No it doesn't.

        It makes me want to kill others. :)

      • I'm using JIRA at work. In combination with Fisheye (web based view into revisions), Bamboo (automated builds), and Crucible (offline code reviews) you get a pretty sweet system for team development. All of these tools integrate pretty seamlessly with svn. Only caveat is that it costs money.
    • Re: (Score:1, Informative)

      by justhatched (1291470)

      trac [edgewall.org] + subversion works well.

      Yes it does, very minor issue with Trac + svn tho, it needs to be on same server or you need to frig about with svn replications for the integration to work nicely.

    • by MadHakish (675408)
      I've been using Redmine to host approximately 60+ projects for our entire organization from standard bug tracking to project management. Wiki,Forum, Bug tracking, easily extensible, ACL's, Sane project management features, integration to SVN, and everything else I've identified as a need is built right in.

      All users auhenticate via LDAP, SVN also authenticates via LDAP through apache and is accessible via the web interface. SVN integration is quite good, and nearly every feature we've determined a requirem

    • by melonman (608440)
      We tried TRAC, and switched to BugZilla after several of our staff refused to use TRAC anymore. The way of handling parallel posts is particularly bad, ie 'throw away one of the posts so you can't even reclaim the text to submit it again'. Bugzilla isn't ideal in my view, but we like it a whole lot better than Trac.
  • by Baricom (763970)

    The best issue tracker we've seen for Subversion, by far, is Trac [edgewall.org]. We're not crazy that it's written in Python (not that anything is wrong with Python - it's just proven difficult for us to hire people with language familiarity beyond PHP). However, the integration between Subversion and Trac appears to be very good.

  • I use Trac. I also use it for the wiki functionality, and Milestone features. Good piece of software, if it's what you're looking for.
    Pity the Auth wasn't cleaner.

  • TortoiseSVN (Score:1, Redundant)

    by ya really (1257084)
    Probably the most user friendly one I've found (assuming you are working in the windows enviroment and sshing into a linux box). It's very similar to TortoiseCVS, if you have ever tried that. TortoiseSVN integrates right into explorer as well for ease of use. Link to their site: tortoisesvn.tigris.org [tigris.org]
    • Re: (Score:1, Redundant)

      by ya really (1257084)
      Not sure how well you looked at TortoiseSVN's site, they have quite a bit of documentation, faqs and such on there. There's also alot of 3rd party documentation/tutorials on it floating around the web at places such as here [ilstu.edu]
    • Re: (Score:3, Informative)

      Tortise isn't an issue tracker, it's a front end to Subversion. The OP wants an issue tracker (Think Trac, Bugzilla, Redmine, etc) which is a different beast.

      • Tortise isn't an issue tracker, it's a front end to Subversion. The OP wants an issue tracker (Think Trac, Bugzilla, Redmine, etc) which is a different beast.

        Oh, I guess I missread, thanks for letting me know. In that case, I'd reccomend Mantis. You can directly integrate it into SVN if you want. Here's the tutorial I used to integrate them together [alt-tag.com]

        • Re: (Score:3, Informative)

          Mantis looks OK but I prefer something that doesn't need quite as much work to integrate :)

          Redmine and Trac both just accept a repository path and bam - integration. Redmine does a bit of a messy with the repo by reading all the changeset information the first time you connect it to the repo though; that can take a long time if it's a well-established repo.

  • are two different things. You can't expect finding much about issue tracking in a version control tool's documentation.

    So what about:

    * Bugzilla
    * Trac
    * Mantis
    * Roundup
    * RT
    * ???
    * Oh, never mind

    • by EvanED (569694)

      ...are two different things

      In part that's because of the Unix philosophy of keeping programs separate. But you can get a lot of benefits if you can combine them, either into one program or through plugins. You can easily get things like asking your issue tracker "what revisions patched this?" or ask your VCS "what bugs does this commit fix?".

      You can do this ad-hoc, for instance by making an issue tracker post like "fixed in r2901" and putting "fixes bug 425" in your commit messages, but it's nice to have th

  • Have never used it but JIRA is an excellent issue tracker, and their integration with FishEye (Code repository browser) looks pretty snazzy. Not sure if it would fit your specific needs.

    http://www.atlassian.com/beyond/link_to_source.jsp [atlassian.com]
    • I have had positive experiences with JIRA. The integration with svn works fine.

    • There is a subversion plugin to JIRA which is free and will automatically scan for bug references. It's pretty good.

      • by KGIII (973947)
        I think that it is only good for non-commercial projects. I got to "play" with it recently for a client who is building out a site for a commercial project. I will say this, their support is fantastic as a paid client.
    • by cathector (972646)

      i'm currently using SVN w/ Tortoise + Jira + Fisheye, with a team of maybe fifteen pretty active users and fifteen additional casual users. SVN & Jira make a good combo. Of the three of them, Fisheye is definitely the weak link for me. It's comparatively slow as a dog, and the interface leaves much to be desired. I think much of Fisheye might benefit from being moved from a web app to a client app like Tortoise. I've used Bugzilla and Mantis in the past, and Jira is definitely slicker.

  • Redmine (Score:5, Informative)

    by thegrassyknowl (762218) on Sunday July 27, 2008 @08:53PM (#24362779)

    We've been using Trac for a long time and it worked well.

    We since discovered Redmine which does about the same job, is themed prettier and seems to be a bit easier to use. All in all Trac and Redmine both do about the same things.

    Redmine has a built-in user management, which I'm taking advantage of in our SVN/Hg web server to authenticate users with (single sign on)

    Redmine also has support for multiple projects in one tracker, whereas trac needs multiple installs for multiple disjointed projects. The workflow manager in Redmine is also really easy to use; no dicking about writing python scripts to control your workflow.

    Redmine talks to Svn, Git, Mercurial, Bazzar and a couple of other source control tools, which is useful if you ever need to move on to those tools. Trac is pretty rooted on subversion, though it does have a Git plugin.

    Both are pretty easy to install, but I had Redmine up and running in about 4 minutes whereas it took a bit of messing about to get Trac running.

    Redmine also has the manager friendly theme (think that horrible facebook style) so managers will goo and gaa over it then sign off that it be implemented.

    • by statusbar (314703)

      Wow! Thanks for the info on Redmine!

      I'm currently using Trac with the multirepos branch, svn and Mercurial. This works well with multiple projects but the install was not so slick.

      --jeffk++

  • Plenty (Score:5, Informative)

    by c (8461) <beauregardcp@gmail.com> on Sunday July 27, 2008 @08:55PM (#24362795)

    Off the top of my head, you've got Trac, CVSTrac, Redmine, Collaboa... Trac is pretty well established. CVSTrac (AKA SvnTrac when dealing with Subversion) is lean and mean and absurbdly quick to set up. Redmine is pretty new, but seems to have picked up a lot of good ideas. Collaboa looks nice, but development appears to have stagnated.

    There's plenty of others, though. Commercially, things like FogBugz also have Subversion integration. But it's not exactly hard to find all this out: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems [wikipedia.org]

    Be aware that once you lock yourself into a combination of SCM and issue tracking system, migrating to another SCM is absolutely hellish. Hope you really, really like Subversion.

    [disclosure: I mostly maintain CVSTrac]

    c.

  • I personally really like Unfuddle [unfuddle.com] as a commercial hosted solution and Redmine [redmine.org] if you either want full control. Both work well, and both support git (Redmine does others) giving you a future upgrade path without having to throw everything away.

    Damien

    • I've been using unfuddle for a couple months now, and I'm not really satisfied with it. The interface is nice, and it seems to have a lot of features that are nice, including the SVN integration, markup used everywhere, ticket views, etc.

      However, there's a lot of things I don't like about it. The email format is horrible; groups multiple unrelated messages about different things in single emails, always with the same subject, and does that multiple times a day. Makes no sense to me, and it's really hard

  • by knewter (62953) <<josh.rubyist> <at> <gmail.com>> on Sunday July 27, 2008 @11:09PM (#24363733) Homepage

    In all seriousness though, I've ditched svn for a DVCS (git) and I'll never go back. I used svn for maybe forty projects and loved every second of it until I used git for the first time (ok, it took a lot of reading to convince myself git was worth the time investment required to grok another VCS).

    Branching in git is so unbelievably natural. I've got my bash set to add (working) to the end of my prompt if I'm in a git repo and I'm on the "working" branch, for instance.

    I will say, the designers on my team dislike git significantly. Their lives were almost entirely covered with "svn co/ci" and the idea of having to keep a remote tracking branch, merge a work branch with it, push the changes to the master repo...this just irritates them. But once we find a good way to appease them, it will have been so unbelievably worthwhile.

    Anyway, I do believe ease of forking/branching/merging to be the killer feature of a VCS and I think git has got it completely right. I've never tried mercurial (hg) but I've heard great things about it as well...but I have zero dissatisfaction with git, and a project I'm working on has even adopted the short-hash conventions git uses with much success.

    Erm, enough.

    • by dubl-u (51156) *

      Anyway, I do believe ease of forking/branching/merging to be the killer feature of a VCS and I think git has got it completely right. I've never tried mercurial (hg) but I've heard great things about it as well...but I have zero dissatisfaction with git, and a project I'm working on has even adopted the short-hash conventions git uses with much success.

      I take it you're working with a distributed team? For teams that are all in one spot, I see more of them them moving away from branching. The notion being that if you have a lot of people trying to collaborate tightly, branches let them run off in all sorts of different directions, which gets painful.

      So that a VCS makes branching easy is not always a plus for me; when something's dangerous, I like it to be hard.

      • by xenocide2 (231786)

        Branching is never "hard enough" the trouble always comes in the form of merges. Ideally, merges would be easy and you wouldn't care about how hard branching should be. Of course, prolific branching requires a completely different attitude to development, with integrated patch review, short lived branches and constant communication.

        What I don't see, is how that translates into "hard for people in the same office" or "trying to collaborate tightly". I can't think of a better description of tight collaboratio

        • by dubl-u (51156) *

          I'm having trouble following both your answer and your question, so let me try again.

          The best single teams I work with almost never branch. They all sit in the same room, talk frequently, check in every few hours, and don't go home with work uncommitted. Except for occasional very rare production issues, they don't branch; they always work off trunk.

          For people in a good team-of-teams situation (e.g., 30 engineers in the same office, working on the same code base, in 5-10 teams) I see slightly more branching

          • The main reason that people don't use branching more is because it has been very painful to merge the branches together again. The current generation of DVCS tools were all designed to mitigate this as much as possible.

            I suspect much of your fear is from these painful merge experiences.

            With plugins that can two-way-synch between the DVCS tool and Subversion available for several of the DVCS tools, there's no real barrier to trying them out, using them for branching, and discovering how much less painful mer

            • To a degree, I agree with the grandparent. Branching is easy, and merging should be hard if the changes have diverged enough to encourage people to commit early, and commit often. A version control system that makes it easy for people to maintain their own forks is not really in the project's interest because it encourages forking. I've seen this with developers using svk, which builds a distributed RCS on top of svn - they check out, check in a load of changes into their local svk, and eventually dump a
              • by xenocide2 (231786)

                Thats why I said you need a change in culture. Instead of building a pile of patches that nobody can review and dumping it in later, merge branches often. I can't say I know which system is best, but making branching painful because merges might be painful is cutting off the nose to spite the face. Make an effort to think about this, and make it clear what needs to be done.

                If you've got five programmers in a room, maybe the only VCS feature you want is revision history. If you scale it up to cubicle farms,

                • by dubl-u (51156) *

                  Thats why I said you need a change in culture.

                  You're talking about culture and technology as if they're two separate things, but they aren't at all; each influences the other.

                  Take the modern American lifestyle, which people openly call an automobile culture. That technology has deeply shaped the culture, and that culture shapes the technology. The recent rise in American cities of a cycling culture also has a symbiotic relationship with technology. Improvements in clothing, cycles, and locks started things out. Now we have things like Internet-enabled

            • by dubl-u (51156) *

              The main reason that people don't use branching more is because it has been very painful to merge the branches together again. The current generation of DVCS tools were all designed to mitigate this as much as possible.

              Are the tools really the problem?

              The major merge problems I've seen sure weren't helped by the tools. But the essential problem seems to be managing complexity. With a single trunk and frequent checkins, you have one true version, plus a bunch of tiny variations whose differences get hammered out daily. Branching creates a lot of opportunity for conceptual drift. Keeping track of one main line is hard enough; keeping track of what a bunch of other teams are doing in their own branches seems a lot harder.

              Fu

          • by theCoder (23772)

            I imagine that those small teams of people are probably working on a piece of software that takes a few minutes to compile completely. Try working on a piece of software that takes hours to compile. In that situation, when one of your teammates makes a change to a core file that is included all over the place and the whole team has to stop working while everybody recompiles, you'll learn why branches are good.

            Where I work, we probably take branching a little to far. Changing the code involves a minimum o

            • by dubl-u (51156) *

              Very interesting! Thanks for taking the time to post that.

              The teams I've seen that have this problem mainly have solved it in other ways, like pre-commit automated testing and distributed build tools. Or they're working with languages that do more of the work at run-time, so the cost of change isn't as severe. But it's great to hear that you folks have the branch-heavy approach working pretty well for you; every one I've seen personally has always been a terror.

              I take it we're talking a C++ code base here?

              • by theCoder (23772)

                Yes, it's C++, so include changes can cause big compiles.

                It's hard to say exactly how many people use the baseline. There are probably 2 dozen active developers, but probably more than 50 individuals who have worked on it. As far as releases, there is the core system which is released about once a quarter, with interim releases done about once a month. Then there are more program specific addons that use the core that release on their programs schedule. Some of the programs do internal developer release

            • by aevans (933829)
              This is the one post that convinced me to give distributed VCS a try. And we don't even have long builds! But being able to branch for integration tests is a great idea, which would be unworkable, unless, as you say, we use "merge" branches as well. Most of the time, changes that have passed tests in the trunk 'dev' build should be accepted, but any files touched by bugfixes from the previous integration build can be manually verified -- as long as everyone's honest. Likewise, only files touched last by
    • Re: (Score:3, Insightful)

      by cathector (972646)

      I will say, the designers on my team dislike git significantly. Their lives were almost entirely covered with "svn co/ci" and the idea of having to keep a remote tracking branch, merge a work branch with it, push the changes to the master repo...this just irritates them.

      .. and their irritation seems unjustified ?

    • As you can tell, from their use of the word "plumbing" for the actual code, and "porcelain" for the user interface..

      I hate to make you think about moving again, but why not try Bazaar? It allows both the natural branching you like and the pedestrian centralized version management that your designers are used to - at the same time!

  • Jira by far (Score:1, Informative)

    by zyrorl (1069964)
    Jira is by far the best, they have legendary support (really they do), and for non-open source products, its probably the best supported commercial product ever. It also has a really good community surrounding it, and by far the best interface. It's also not legendarily expensive. Very affordable from a company point of view. Excellent functionality, pretty much handles anything you throw at it.
  • Flyspray has some good SVN integration, and is by far one of the best trackers i have tried.
  • by Darkforge (28199) on Sunday July 27, 2008 @11:45PM (#24363955) Homepage

    I know I'm not answering your question, but you may be asking the wrong question. Subversion 1.5 "has" merge support, but you still can't do safe bi-directional merges. (Wherein you make a feature branch "foo", merge from trunk to foo, foo to trunk, trunk to foo, foo to trunk, etc.)

    Also, you can't safely merge from branch to branch (merging from "foo" to your production "2.x" branch, without passing through trunk).

    Here's the designer of SVN merge support discussing the problem:
    http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=127570 [tigris.org]

    Unfortunately, if you want real merges in an open source project, you're stuck with the distributed source control systems like git, mercurial, darcs, etc. even if you don't need distributed features.

    But you may come to like distributed source control (many people do)... they have tools like "ticgit" that you may like better than some of the other svn-based tools out there.

    • I appreciate all the replies I have received -- even the off-topic ones have been informative. Yours is especially valuable. Thank you, DarkForge, for bringing the very important lack of cyclic merges to my attention. The advice from the svn book (page 94 of r3212) is as follows:

      At the time of writing (Subversion 1.5), once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly ab- sorb new trunk changes, nor can it be properly rei

      • by Darkforge (28199)

        Consider using "distributed" source control in a centralized way. Nobody says you have to use the distributed features just because they're available to you.

        The problem here is that all the smart guys in open source thinking about source control are out trying to solve the "distributed" problem; none of them have brain cycles to spare for centralized SCM, which is a shame, because it means that no centralized open source SCM has reasonable merge support. :-(

        You may also find that the large changing binary

  • Quote from their website: "BUGS - the Bug Genie" is an open source enterprise level issue tracking system, built on open source technology. "BUGS" enhances your development process, by offering an advanced tool to manage bug reports, feature requests and user feedback for your products. Version 2 (currently beta) support SVN integration.
  • Bugzilla (Score:3, Informative)

    by onlau (1164843) on Monday July 28, 2008 @04:11AM (#24365349)

    You can use Bugzilla and Subversion using scmbug (http://freshmeat.net/projects/scmbug/ [freshmeat.net]). It's a set of scripts you use as svn hooks. Setting it up is not really user-friendly but once it's set, well... you don't have to touch it anymore.

    You can solve a bug using the following comment on a svn commit:

    bug 42: resolved fixed
    blablablablah (real comment)...

    BTW it works for other control and bug-tracking systems...

  • Scarab (Score:1, Informative)

    by Anonymous Coward

    Take a look at Scarab (http://scarab.tigris.org). Setting it up takes a bit of time, but it's very versatile.

  • TrackStudio (Score:2, Informative)

    by Lars Fosdal (1053310)
    I am a satisfied user of TrackStudio from http://www.trackstudio.com/ [trackstudio.com] Web-based, affordable, very configurable, and with an easy to configure integration with SVN. You can use most major databases for backend. You can model any number of workflows and have custom fields per workflow, per project or per user. Very effective searching and filtering allowing custom views. Email notification, Digests, RSS, etc. It also has an extensive SOAP interface if you need do some custom integration. It still is a b
    • Forgot to mentioned that is multi-project oriented, allowing you to track your "to-do list" across all your projects.
  • What about http://www.gforge.org [gforge.org]? They have an open source product (based on Sourceforge branch?). They also have an Express Edition (free) and Advanced Server edition (commercial) available through http://www.gforgegroup.com./ [www.gforgegroup.com] I just started looking into their products and I've installed GForge EE, though we haven't really used it in anger yet.

  • Use Trac. My company uses Trac for our SVN repository, and it works beautifully (I'm also the main Trac admin at work, so I'm quite familiar with it).

    It's more than just an issue tracker--it has a full source code browser with diff support and syntax highlighting.

    You can tie tickets and commits very tightly together; Trac supports SVN hooks that can require a ticket to be referenced in every commit message. If you ref a ticket number in a commit message, a comment will be added to the ticket with the text o

  • There's an open source project, SCMBug [freshmeat.net] that seeks to be a glue between SVN and Bugzilla - allowing well-formed checkin comments to comment/close out bugs (of course, getting well-formed checkin comments from developers is sort of like getting 99% uptime from twitter).

    Does anyone have any experience with this tool?

  • Not too long ago we migrated from sourceforge to RT3; the SF VM died and we were already in the process of migrating from prebuilt VMWare services to natively hosted stuff. SF is unfortunately no longer (maybe it never was) available as a project in this fashion, and we were only using it for the tracker.

    RT3 is a pretty decent system, but the interface is rather complicated and cluttered, and modifying it is not as easy a task as one might expect. For example, "resolved" items do not show up in any listin

Recursion is the root of computation since it trades description for time.

Working...