Try our Online Forums, or contact us directly.

FishEye's goal is to allow changesets to be seen as a consistent stream of atomic commits. Revisions are collated into the same changeset so long as:

• They have the same commit comment.
• They are by the same author.
• They are on the same branch.
• The changeset does not span more than 10 minutes.
• The same file does not appear in a changeset more than once.

In Subversion, branches and tags are defined by convention, based on their path within a repository, and not directly defined by the repository. There are a few different layout alternatives commonly used. It is also possible that you are using your own custom layout. As a result you need to describe to FishEye which paths in your repository are used as branches and tags.

It is very important that you correctly define in FishEye the layout you are using. If you do not, FishEye will not know which paths represent tags and branches. This will prevent FishEye from relating different versions of the same logical file across separate paths within your repository. It will also mean that FishEye's cache will be much larger as each tagged path will be indexed separately. This will result in an increase in the initial slurp time and may reduce runtime performance.

When you add a repository, FishEye needs to scan through the repository to build up its index and cache. This scan can take some time. As a guide, FishEye should be able to process about 100KB-200KB per second on an averaged-size PC.

If FishEye is accessing the repository over the network (e.g. over a NFS mount), then you should expect the initial scan to take longer.

If possible, FishEye will monitor and parse the CVSROOT/history file in your repository to quickly work out what has changed. You may want to check with your CVS administrator to ensure this feature of CVS is turned on.

If you do not have a CVSROOT/history file, then a commit will not appear in FishEye until after it has done a periodic full-scan of your repository. You can configure the period of this scan in the admin pages.

On some Linux systems (particularly RH9), there are socket problems between the JVM and the kernel. To fix this, you need to set the LD_ASSUME_KERNEL environment variable before starting FishEye. Add this to the script that starts FishEye:

export LD_ASSUME_KERNEL=2.4.1

The Java heap space needs to be increased to an acceptable size. See the FishEye Tuning documentation for more information.

To run FishEye as a service you can either use SRVANY and INSTSRV to run java.exe or create a Java Service Wrapper. A mechanism to run FishEye as a service will be incorporated at a later stage. In the meantime example wrapper files written by FishEye users can be found on this FishEye forum thread. To install on windows:

1. Unzipping it into the FISHEYE_HOME directory.

2. Run Fisheye-Install-NTService.bat found in FISHEYE_HOME/wrapper/bin.

3. Start the Fisheye Service under control panel.

On Unix systems, the svn:// protocol is usually handled by inetd or xinetd. These daemons apply, by default, a connection per second limit to incoming connections. Any connections above this rate are rejected by the server. You may either have your system administrator increase the connection rate allowed for svn connection by updating the xinetd configuration or specify a connection per second limit in your FishEye repository definition to prevent FishEye from exceeding the xinetd limits.

FishEye gives you a logical view of your branched files so you can see activity on a single file across multiple branches/trunk.

For merge management the main advantages with FishEye come from its searching features. If, when you check in a merge result, you record the revisions merged, you can find this info in FishEye easily for the next merge operation.

As an example, let's say you have a branch dev created at revision 1300 from trunk. Development has proceeded on both trunk and dev. At some point you wish to add the latest trunk changes into the dev branch. Let's say that is at revision 1400. When you check in the results of this merge, you would use some standard format checkin comment such as:

merge from trunk to dev 1300:1400

When you come to do the next merge, say at rev 1500, you can use FishEye search to find this checkin comment and know what the starting point for the merge should be. You can then check this in as:

merge from trunk to dev 1400:1500

Merges back to trunk from the dev branch are managed in the same way.

SVNKit may have problems with older version Subversion servers - versions 1.1.x and prior. If this is the case you should either use the native JavaHL layer or upgrade your Subversion serv er to a more recent version.