And my users tend to get rather disappointed when they loose it. In real life it turns out that databases allready have a lots of data. That said, the schema is usually only a part of the equasion. With the SSDT tools you have the 'lastest version' of the database definition, allowing you to easily make schema comparisons and generate schema upgrade scripts. Most have excellent Visual Studio integration. See the page Tuning Fisheye for instructions and the related memory guide, Fix out of Memory Errors.I have tried both RedGate and Visual Studio's database project and I prefer the storing the database definition in the database project.Īs soon as the database becomes part of the solution, you can use your preferred source control provider. Configure your index threads & memory usage to an appropriate level. See this existing Knowledge Base document for more information. Avoid using symbolic links to refer to your Fisheye install directory location. Some diff results (and line numbers in diffs) may appear incorrect in files where $Log is used. This is because Fisheye does not handle the $Log RCS expansion keyword correctly. Avoid using the text $Log$ in your CVS commit messages. See the documentation on the 'Excludes' option. It is recommended that you exclude this directory from being indexed. Fisheye will take a long time to index this tag/branch as it needs to index its entire history, which can be very large. You may have a branch or tag that you delete and recreate often, for example a latest tag which holds the latest release. Exclude tags and/or branches that you delete and recreate often. Best practices for Subversion integration can be found here. It's best to stick to one of the standard conventions recommended by Subversion. Decide on your Subversion tag and branch conventionsĭecide what conventions you are going to adopt for your subversion repositories and then stick to them. The result is that small changes can be essentially unmeasurable and cause a large amount of re-scanning.Ħ. This especially applies to Subversion, because of its concept of 'cheap copies'. The more often you make major changes to the structure inside your SCM, the more scanning is required for Fisheye to keep track of its status.Make these changes sparingly and as infrequently as possible. Avoid treating an SCM like a file system - don't alter the structure or move items around without a significant reason for doing so.This can garner significant performance gains. A logical structure will make it simpler to exclude certain branches when they become less relevant to work in progress.Split your repositories into logical components if you can (For example, by product or project). Do this by defining the 'Skip Labels' Repository Detail.ĥ.Perforce Labels can be slow to process, and thus cause Fisheye to index slowly in certain environments.Consider skipping Perforce Label processing if not important Do this by using 'Allow' and 'Exclude' Admin settings. You may also want to exclude large branches/tags that have been deleted (even though they are deleted in your repository, Fisheye will still index them as they once existed). Exclude directories if you don't need them.įor example, not everyone may need to access a developer's personal branch on the repository, so you can exclude it from the repository scan. Do this when defining your Perforce or SVN repository. If your repository is really large, consider starting at a sensible revision (If you cannot install Fisheye on the server where Subversion is running, use svnsync to mirror the repository onto the Fisheye server). See Improve Fisheye scan performance for more information. Use the file:// protocol for fastest indexing performance. Ensure your Fisheye scan performance is as fast as possible.
0 Comments
Leave a Reply. |