What can FishEye do that we cannot get from other tools for a git repository?

Question

We have decided on Jira and Confluence and are now looking at other Atlassian tools that may make our lives easier.

I understand that FishEye allows all kinds of visualization of a source code repository that the native tooling for CVS does not. We have, however, migrated to git, which has a large ecosystem of very useful tools.

Question is: Can FishEye tell us something useful we cannot get from the native tools? (Or commercial tools at a competitive price)?

Answer 1

One of the main benefits we get from using FishEye is layering on Crucible on top of it, facilitating remote code reviews.

Answer 2

Update 2022: The BitBucket server option will be discontinued in Feb. 2024.

A migration to the Cloud offer will then be mandatory.

---

Update 2018: Stash is called BitBucket server now...
Update January 2013: it is called Stash now.
(see sendmoreinfo's comment)

---

Original answer February 2012:

From FishEye2.7, you can not only access remote repo, but also create within FishEye server new Git repo.
See "the FishEye manual page", "Creating a Git repository", and "Enabling Repository Management in FishEye".
The blog post "FishEye in Practice: Setting up your own Git repositories" also presents that feature, listing the goals for that feature:

• Allow enterprises to get or migrate to Git repositories behind their firewall
• Make it simple to configure repositories permissions for teams

That means FishEye will leverage the access layer (like the Apache Server on top of which FishEye is running) for internal Git repo access.

It will also provide basic authorization mechanism, meaning you don't have to setup a separate infrastructure like another Apache+Gitolite in order to manage internal repos: you can directly use the FishEye server.

Answer 3

We moved away from using FishEye cause it was slow and bulky on our limited servers. Much happier using JIRA along with Git on GitHub. Several of the visualization features that FishEye touts, are not supported in Git as well. I'm a big Atlassian fan, I just think FishEye isn't one of their finest tools for Git work.

Answer 4

Personally I like Fisheye, but that's given a medium-sized dev environment and a semi-complex branching/development strategy where monitoring the current state of the repo was pretty important.

At my last job our major product was a line of server-side Java, white-boxed SaaS products where all of the billing and system integration was handled in house. Although most people were Emacs/command-line hackers, we still used Fisheye on top of all of our major product lines.

Caveats

• This was with SVN, not git/hg, so take this with a grain of salt.
• There were other SVN hooks that were built in involving Bugzilla that I'm not 100% sure on how they worked

Reshuffled engineers working on products that did not have Fisheye were typically unhappy for the following reasons:

• Refactoring Typically you're moving files around, renaming, merging related changes and the like. Fisheye's search by base name will return files that have been long since deleted with their history maintained, so even if you mess up the history in the repo, you have a sense of what the previous changes were. For a code base that was experiencing some very real growing pains from a sudden expansion to the company, this was a huge help

• Code Ownership/Review Even without a robust code-ownership/review process, you can opt-in to particular project/repo changes with Fisheye. For team leads and the like, it's a very simple way to stay on top of what other people are doing when they are changing things and why, whether you want to receive email spam or set up an RSS feed for the repo. If you're managing multiple projects at once, that could be a big deal. I had an RSS feed set up for my first major project so I could see how it was changing, but the real benefit is to monitor API-related projects as they change

• Usable Not all of our engineers are command-line hackers. This is particularly true for some of the frontend engineers that handled HTML/CSS. As much as some people tend to fall-back on command line tools when possible, performing the run-of-the-mill file diffs and 'Who reverted my change and when?' it is easier to handle in-browser diff tools than doing 'svn blame' and the like.

All that said, I will say that if I were doing a dev shop from the ground up, I wouldn't touch it at all unless I needed visualization of the full project rather than a specific file or two every now and again, which probably means the following things are true:

• The size of my group hit roughly around 10+ engineers of potentially non-technical backgrounds and is in need or reorganization from an ad hoc strategy
• Branching/tagging serves a number particular needs as much as it does general versioning
• Code ownership and review gaining traction as a loosely enforced idea at a minimum rather than a hardline stance against it because of resource contraints
• Communication among the engineers is an increasing issue (whether it is sheer noise, or lack of it). This includes casual conversation to straight documentation

I'm ignoring any analytics/tools integration as well. Partly because I assume that if you're comparing Fisheye to anything else, you should also be looking at how much extra work it would be to maintain Fisheye vs. another solution vs. winging it, but also because I have never worked with more than one Atlassian product at a time.

In your situation, I would also look at the Jira/Fisheye integration parts and see if that a feature set you need at the moment (or at all) when looking at other commercial options.

Answer 5

I really like the integration between fisheye and Jira. Having your projects in jira linked to your repository in fisheye is awesome. You get the "source" tab in jira. Then when you commit with the bug/task id in the commit comment, the files from the commit show up in the source tab in jira and you can just click through to see exactly what changed in the commit for that bug/task. Admittedly I've only done that on SVN, so I can't say for certain if it works with git, but it would be worth investigating.

Another cool feature is that you can create a jira defect from within the crucible review. I can highlight the offending line of code, create the defect, and then the creator gets a warning if there are unresolved bugs related to the review when they try to summarize/close the review.

Working on a 100% remote team, I find Crucible on fisheye to be invaluable for code reviews.

Answer 6

For me the interesting part is that I can quickly figure out what commit are related to an issue. It will be part of JIRA itself.

So if I repport a bug on a project I don't directly work on, I can check how the fix is as I would expect, without having to clone the project, then search the commit history log.

It also force the developers to put issue tags in their commit message.

Code review is also nice to have, but so far we don't use it really often.

Answer 7

There are two things that Fisheye+Crucible gives my team that seems to be lacking in other professional code review tools:

1. The ability to combine changesets from more than one repository into a single code review. With our projects spanning multiple repositories, a full change may include changes across repos. Having all changes across repos available to review in one code review really helps with the full picture of the impact to the product.
2. The ability to upload and attach files. Especially with changes to UI elements, it is great to have screenshots of the changes attached to the code reviews. It has also been helpful for reviewers to have reference documents attached to the code reviews.

Answer 8

FishEye provides an nice EyeQL query language https://confluence.atlassian.com/fisheye041/eyeql-reference-guide-847745659.html

FishEye can perform text searches across multiple repos and will return results with context.