All Versions
Fisheye 4.2 DocumentationFisheye 4.1 Documentation
Fisheye 4.0 Documentation
More...
This page explains the limitations of the FishEye Starter license and provides general information about using this license in production.
On this page:
Starter licenses are low-cost licenses that allow small teams to make use of Atlassian products (see more information ). FishEye Starter licenses were introduced with the release of FishEye 2.0.5 (October 2009).
FishEye Starter Licenses are restricted to no more than:
If you have more than five repositories, FishEye will prevent more than five repositories from being enabled at any given time. Administrators can control which five repositories are enabled.
If you exceed more than ten committers in a repository, a warning will appear at the top of pages for the entire system, stating the following:
NOTE: This repository, (repository-name) has more than ten committers which exceeds the limts for your Starter license. Indexing has stopped. To fix this, you can 'Evaluate', 'Upgrade' or 'Reconfigure your repository'.
Screenshot: Warning for Starter License Limits
The links in this warning will lead you to the following solutions:
30-day evaluation licenses are available to allow you to try out FishEye and other Atlassian products. You can select a license that allows more users than your current license.
You can upgrade your license at any time (via the Atlassian online store), which will remove the committer and repository limits which apply to the Starter License. Please ensure to restart your repository, after the license upgrade, to ensure the changes are picked up for the new committer limit.
This option lets you configure your repository to remain within the limits of the Starter License. You can take the following actions to reduce the scope of FishEye's indexing:
Once you have reconfigured your repository, you will need to re-index the repository, allowing you to remain under the limits of the Starter license.
Question | Answer |
---|---|
What happens when the 11th unique committer is encountered during indexing? | For all SCMs other than CVS FishEye will index all revisions up to but not including the revision that introduced the 11th committer. Since CVS is indexing is file-by-file based, FishEye will index files until it reaches the committer limit. Remaining files in the repository are not indexed. This means only files which have been indexed will be displayed in changesets and changesets may be incomplete. |
What happens when a FishEye instance with a Starter license is started, using existing indexes with more than five repositories? | FishEye will only start indexing on the first five repositories. An administrator can use admin UI to adjust which repositories are enabled and hence control the five repositories that are started. FishEye should then be restarted. |
What happens when a FishEye instance with a Starter license is started, using existing indexes with one or more repositories with more than ten committers? | FishEye will display all information currently indexed but for each repository that has reached the ten committer limit, no further revisions will be indexed. |
What happens on upgrade from a Starter license, if indexing has been paused due to the committer limit being reached? | On restart of FishEye, indexing will resume for all repositories. Each repository can restarted individually to avoid restarting FishEye. Due to the nature of CVS indexing, we recommend reindexing any CVS repositories which have reached the committer limit prior to the license upgrade. |
What happens when upgrading from a Starter license, when repositories have not started due to the repository limit being reached? | On restart of FishEye, all enabled repositories will start. Each repository can restarted individually to avoid restarting FishEye. |
What happens if my evaluation license has expired and I upgrade to a Starter license, however I have exceeded the Starter license limitations? | As described above, a maximum of five repositories will start and for any repository with more than 10 committers, no further indexing will occur. All existing indexed content is retained and can be viewed. |
What happens when downgrading to a Starter license, where the repository limit has been exceeded? | A maximum of five of your configured repositories will start running. The remainder will not start but will continue to be available. |
What happens when downgrading to a Starter license, where the committer limit has been exceeded for one or more repositories? | No further indexing will occur for the repositories where the |
18 Comments
childnode
Nov 08, 2010This FAQ does not tell anything, how the Committer mapping will affect on the "committer restriction"
childnode
Nov 08, 2010ok, I tried it myself: Mapping does NOT take any affect on the committers restriction!
Anonymous
Jan 12, 2011Indeed... That's a pitty :(
Anonymous
Jan 12, 20115 is so limited. If the same case that JIRA limited for 5 project, no one will borther as well. We are just a small starting company, but 5 is sure not enough.
childnode
Jan 21, 2011the clue is, "deactivated" users are NOT counting into license in Jira e.g. In Fisheye they do ;(
So generally the 5 users restriction is ok to me, but long term projects with historically a totally different team members (which are no longer present in) will exceed this limit.
The hints as like reducing the commits beeing indexed (starting revision) is not good as long all code not changed before this date is not visible in Fisheye, not either as "anonymous" code ;/
Anonymous
Jan 20, 2011How to set a "Starting Point" for CVS repository?
childnode
Jan 20, 2011I fear that this is NOT possible, as long CVS is not a revision based VCS as like SVN. So There is no revision number you can say "this is the start point". Each file is versioned for it self, typically starting with 1.0.
The only thing that might be useful, is to set a start date. But this might result in incomplete changelogs too..
I promise there is someone else who already made a ticket for this, take a lokk here: jira.atlassian.com (http://jira.atlassian.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+FE+AND+(summary+~+%22\%22start+revision\%22+%2B+CVS%22+OR+description+~+%22\%22start+revision\%22+%2B+CVS%22))
For git / HG see http://jira.atlassian.com/browse/FE-2894
Anonymous
Jan 21, 2011Thanks.
I already checked JIRA and found FE-2928, the status of this ticket is "unassigned".
Damien Joldersma
Aug 15, 2011I get the limited user licensing model, I appreciate it and the value proposition for both Atlassian and it's customers.
However, I believe essentially equating the number committers as the same as the number of users is just a detraction from an otherwise awesome and amazing system; the fact that I accidently commited from a machine with not quite exactly the same VCS config for my username (I myself have 3 identities over the course of this project, I am still only me) just triggered my system in to not being able to index and therefore unusable.
I don't think that the business folks who put this together would wish for this kind of user experience. I believe they want a "10 user limit" for fisheye, i.e. 10 different people should be able to intereact with a sourcecode base, regardless of the content - perhaps all of the commiters are not hyperlinked to fisheye users, no big deal. I think that there should be unlimited username mapping (if someone wishes to abuse, they will have bogus info in the tool, it will be self-enforcing) and that mappings should not count towards committer limit. I do not think there should be any limit to number of commiters, if you want to limit the number of Users who can login or get mapped to fine, but otherwise just print 10+ commiters as plain text, but to stop indexing and make it unusable is totally unacceptable: I cannot back out my additional username change, I cannot adjust my sourcecode starting point and nor can I change my repo to only look at a subset.
I have not had anyone new join the team, I have no new commiters, and I am unwilling to consider purchasing a higher number of commiters in our license because of a one-time config error; we are only 3 developers who happened to use up their user-mappings before we even knew about such strict fisheye licensing rules about your version control username, 3 people with 3 different emails/name spellings = 9 users according to this methodology; there are not 9 users: there are 3 and the spirit of this 10-user fisheye liscense should cover our reasonable usage.
In addition, I only have 9 commiters listed in and I am unable to even get to the 10th user limit they are describing, I got the error message on the 10th not the 11th ( so above restrictions should read: 9 committers total per repository, the 10th will make your index unusable ).
Damien Joldersma
Aug 16, 2011I hope I wasn't too hard core in the above comment thread, I think the gist of the post is still reasonable and worth considering, but in my case with Git, I was able to work around with the following:
Anonymous
Sept 30, 2011Is there any workarounds about this matter? I'm in the same boat, and there are not solutions from Atlassian part...
mwatson
Sept 30, 2011If you are talking about the accidental overrun of the committer limits, then there is a workaround: Git or Hg Repository exceeds number of allowed Committers
Anonymous
Jun 06, 2012This "workaround" is weak at best. In the case of a Hg repository you are re-writing history (see Hg wiki for information) and is generally a bad idea. When you use Hg convert you get new changeset hashes basically making it a new repository. Now merging with a separate repo that was cloned becomes impossible ore just a big mess (such as a stable/release repo or a repo that is a next version).
The ideal solution would be allow the user mappings to alias the users on import. Yes I understand that had licensing concerns since people could alias a lot of users under a single one to remain under the license limit, but that would make the product less than useful.
The current implementation screws anyone who has erroneous commits (bad username), a long history with users who are no longer there (not active), etc. – yeah pretty much everyone else. So if I have a small to medium team with turnover or contractors or whatever in my repo I've got to artificially inflate FishEye licensing to deal with my history.
Piotr Bober
Jan 17, 2012I managed to rebuild a CVS repository and fit into the license limits concerning commiter.
There were above 20 commiters in repository but only 8 currently active (others were not working in the company anymore).
If you take a quick look into the RCS files in repository, you will notice that they have a pretty simple structure. I decided to move the author of the commit into the comment section and create a dummy-user-bag, to which non-active users were renamed. This way you can keep the entire information.
The whole thing required a bash and awk scripts and one sed command.
If anyone is interested, let me know and I will create a blog post about it.
Anonymous
Feb 24, 2012Yes please, that sounds exactly for what i'm searching for. (and if i look through the thread, i'm not alone)
Piotr Bober
Mar 04, 2012Here's the post about rebuilding the CVS repostory:
http://skarbonkait.blogspot.com/2012/03/cvs-rebuild-to-fit-into-fisheyes.html
The blog is in general in polish, but the post is in english. It's pretty long, but as the repository is a sensitive matter, so I encourage you to read it carefully.
Have fun and good luck
David Chung
Apr 04, 2012To be clear, is the 10-committer restriction in place only for the starter license? If we were to purchase the $800-level license, would the committer-count restriction be lifted?
David Chung
Apr 04, 2012Actually, I found my answer: http://www.atlassian.com/licensing/fisheye