Best Integrated Issue-Tracker For Subversion? 99
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?"
trac (Score:5, Informative)
Re: (Score:1)
Re:trac - no ... (Score:4, Informative)
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)
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 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).
RT ! (Score:1)
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:3, Informative)
Re: (Score:1, Informative)
Re: (Score:3, Informative)
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)
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)
"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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Comment removed (Score:5, Informative)
Comment removed (Score:5, Informative)
Re: (Score:3, Interesting)
Bugzilla's demo site is http://landfill.bugzilla.org/ [bugzilla.org] - go ahead and file junk bugs there, nobody would care.
Re: (Score:2)
Re: (Score:2)
fugbugz was so must easier to use, but it to has some quirks to(something about rel
Re: (Score:3, Informative)
Bugzilla (Score:5, Funny)
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. :)
Re: (Score:1)
Re: (Score:1, Informative)
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.
Re: (Score:1)
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
Re: (Score:2)
Trac (Score:2)
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.
Trac? (Score:1)
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)
Re: (Score:1, Redundant)
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.
Sorry, I missread topic, try Mantis (Score:3, Informative)
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.
Re: (Score:3)
Re: (Score:2)
I like bzr -- I honestly couldn't choose between hg and bzr, so I eventually picked it for non-technical reasons (bzr is used by Canonical).
However, if you do go with a distributed system, you may want to take a look at Ditz [rubyforge.org] -- it's an issue tracker which uses flat textfiles as a datastore, with the intent that you'll just check those into whatever version control you're using. That means the opening or closing of an issue is directly tied to a commit.
Which means it will work well with any SCM, but is espec
Suggestions for CVS? (Score:2)
I'm committed to CVS(NT) (mayhaps a bad choice) with TortoiseCVS as the client. If anyone can suggest an issue/defect/bug tacking solution that plays nicely with CVS, that would be great! We tried installing Mantis, but it was a bit too complex for our needs, people rarely used it.
Ideally, it could support multiple variants of the same project (same branch, but different inputs), and different levels o
Re: (Score:2, Interesting)
What in Mercurial makes it superior to git?
As a user of both, my conclusion is that git is comprehensively superior to Mercurial and Subversion. The basis of that conclusion includes:
version control and issue tracking... (Score:1)
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
Re: (Score:1)
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
FishEye + JIRA? (Score:1)
http://www.atlassian.com/beyond/link_to_source.jsp [atlassian.com]
Re: (Score:2)
I have had positive experiences with JIRA. The integration with svn works fine.
Re: (Score:2)
There is a subversion plugin to JIRA which is free and will automatically scan for bug references. It's pretty good.
Re: (Score:1)
Re: (Score:2)
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)
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.
Re: (Score:2)
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)
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.
Unfuddle or Redmine (Score:2)
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
Re: (Score:1)
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
Subversion is so 2007! (Score:3, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Merging should be easy (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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,
Re: (Score:2)
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
Interesting (Score:2)
Re: (Score:1)
Re: (Score:2)
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
Interesting. (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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?
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
But the point is, branching and merging are EASY in git, and not in the least harmful unless you've got problems in your project management flow in the first place.
Oh, well if git only good for places that don't have any problems, actual or latent, then recommending it to everybody on Slashdot certainly makes sense.
Re: (Score:3, Insightful)
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 ?
git is a little .. bare metal (Score:2)
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)
Flyspray (Score:2)
Subversion "has" merge tracking (Score:4, Informative)
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.
Re: (Score:1)
Re: (Score:2)
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
BUGS - The bug genie (Score:1)
Bugzilla (Score:3, Informative)
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)
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)
Re: (Score:1)
What about http://www.gforge.org? (Score:2)
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.
Trac (Score:2)
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
SCMBug? (Score:2)
Does anyone have any experience with this tool?
Currently using RT3 (Score:1)
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