[Other doc versions]
[Doc downloads (PDF, HTML, XML)]
A: In FishEye 2.7 we added basic capabilities to host and manage Git repositories within FishEye. However, as we were planning future releases, we realized that the architecture of FishEye, built to index, browse and search across various SCMs, was not adequate for a DVCS repository management tool.
Therefore we have made the decision to build a new product, with a clear focus: hosting and managing Git repositories. Instead of a "Jack of all trades", we will have two products that are focused on 2 very different tasks:
A: Internally managed Git repositories were deprecated in FishEye and Crucible 2.8, and support for these was removed for the FishEye and Crucible 3.2 releases. We encourage those interested in Git repository management to check out Stash.
FishEye and Crucible will continue to deliver new features and enhancements to help users browse, search, review and visualize across different Version Control Systems including Git, Subversion, Mercurial, Perforce and CVS.
A: FishEye and Stash are two separate standalone products that do not require each other.
If you are using multiple source code management systems (SCM) at your organization it makes sense to use both Fisheye and Stash. While you are managing your Git repositories with Stash, you can use FishEye to browse, search and reference code from other SCMs including Subversion.
Also, if you are using Git, Stash will provide your Git repository management, and FishEye will be a central place to keep track of changes and search for code across your repositories.
A: Stash will not be available in Atlassian Cloud. If you are looking for a distributed version control solution to use with Atlassian Cloud, we recommend using Bitbucket, our cloud-based Git and Mercurial source code hosting solution. Bitbucket connects to Atlassian Cloud via the JIRA DVCS connector.
Stash Server is a single instance of Stash running on a single machine. It can only handle as much load as a single machine is capable of handling before performance degrades, and if the machine goes down for any reason (for example, hardware failure, network fault, or planned maintenance), then Stash is unavailable to users for the duration of the downtime.
Stash Data Center, on the other hand, looks like a single instance of Stash to users, but under the hood consists of a cluster of multiple machines ("cluster nodes") each running the Stash web application, behind a load balancer. This provides important benefits over Stash Server:
Performance at scale: A cluster of many machines running Stash can handle more load than a single machine.
High availability: If one cluster node goes down, then the remaining cluster node(s) can continue servicing requests so users should see little or no loss of availability.
For more information see Stash Data Center and the Stash Data Center FAQ.
A: Currently Stash does not support Mercurial. We will be gauging demand for Mercurial support as we move forward - - STASH-2469Getting issue details... STATUS
A: Stash works with JIRA 4.3+. However, you will require the latest version of the JIRA/FishEye plugin to view commits in JIRA. See our documentation on JIRA integration.
A: Stash currently integrates with the JIRA issues tracker, SourceTree DVCS Mac client and Crowd user management solution. You can also connect to Stash via Bamboo to run your builds and deployments and we are planning even tighter integrations in the future.
A: No. You can control which users in your external directory have access to Stash, so that the license limit is not exceeded. A user is by definition any account that has permission to log into the Stash application. If you synchronise Stash with an external user directory, you can grant access to Stash to a subset of users, so as to stay below your license limit. The Global permissions page explains in detail how to manage login rights for users and groups in Stash.
A: As stated in the Global permissions document, any user assigned "Stash User" permission or higher, granted to the individual or via a group, will count towards the license limit. Stash will not allow you to grant the "Stash User" permission if this will exceed the license limit while manually adding users using Stash UI. However, if you happen to exceed the license limit by connecting your Stash instance to a User Directory that contains more users than you license allows you to have, Stash will display a banner with the content below:
You have more users than your license allows.
Users will not be able to push commits to repositories until you restrict the number of active users to match your license or you upgrade your current license.
To fix that bear in mind that users don't have to be removed from the database in order to reduce their license count. You merely have to make sure that they no longer have access to Stash via the "Stash User" permission through individual or group assignments.
A: Yes you can, as long as you specify all the
jdbc parameters (
jdbc.driver, etc.) when running the restore. Please read Restoring Stash into a newly created DB for more details.
A: As described in Restoring Stash into a newly created DB, the restore client will only restore into an empty home directory and an empty database. The new database should be configured following the instructions in Connecting Stash to an external database and its sub-page that corresponds to your database type. If you want to use a different type of database or a different user/password, you just need to specify all the
jdbc parameters (
jdbc.driver, etc) when running the restore.
stash.password" and "
stash.password hold the credentials for a Stash sys admin user. They are only used during the backup procedure so that the backup client can lock Stash and instruct Stash to perform the database-agnostic backup. The backup client does not need database credentials because the Stash system performs the database backup.
jdbc.password are only used during the restore procedure when
jdbc.override is set to
true. They are used to connect to the newly-installed database.
A: No. You need to use the same Stash binary as the one originally used to back up your instance. Note that using an older Stash binary will result in an error – downgrades are not possible. See Using the Stash Backup Client for details on the backup/restore procedure.
Once you have restored Stash, you can upgrade to a newer version of Stash following the instructions in the Stash upgrade guide.
A: This error occurs when the amount of data you’re trying to push in one go exceeds Git’s http post buffer. Just run the following command to increase it to 500MB.
git config http.postBuffer 524288000
See Git push fails with 'fatal: The remote end hung up unexpectedly'.