Thanks for the feedback. Letting arbitrary levels of nesting is one of the things that keeps me, and the JIRA product manager up at night.
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.
It's interesting to hear that it's actually a user experience, rather than a technical problem. I was assuming there was some dodgy database code to blame! I will install the 3rd party plugin and see how it works for us though.
Our branches probably put us in the hundreds of millions of LoC category. It's unfortunate that for a long time we were prepared to allow each of our customers a separate branch for each release - each of which potentially has active development on it (not a real branch I know as we don't intend to ever re-merge them). As such we have a lot of code that potentially needs supporting. I'm not actually sure how often they are searched on as I'm lucky enough to work on newer parts of our software but the idea of dropping them from FishEye didn't go down too well.
I believe the guy who did the setup spent some time messing around with performance - I have no idea if he did everything right but he's a pretty smart guy.
I'll definitely take a look at the most recent release though, thanks for the tip.
Oh and thanks for taking the time to reply to my unsolicited feedback!
This feature request is our second highest voted issue (JRA-4446), and one that I personally want to see fixed. For the moment, there is a 3rd party plugin that solves most use cases (Structure Plugin from ALM works).
The key for us as a vendor is making it work without degrading the overall experience. We have seen plenty of other issue trackers implement this, but it really detracts from the overall experience when you don't know what is a task, or a project, or a feature etc.
But we're definitely trying to find a solution.
On FishEye - we have it working on code bases that have hundreds of millions of lines of code, but it often requires some tuning. For example (and one of many such examples), in older versions of Subversion, there was no real way to tell what was a branch, and we rely on 'conventions' such as /branches/ to tell this.
Unfortunately, every code base contains 'mistakes' where someone copied the entire tree into /branches/ or created a branch somewhere else.
There are some easily configured settings that usually make FishEye run a lot faster but explicitly telling it about some of these cases.
But - even saying that, performance was around 50% of the last few releases of FishEye, so the latest versions do run significantly faster in all instances.