CodeCollaborator Frequently Asked Questions

Currently we support Perforce, ClearCase, SourceSafe, Subversion (SVN), CVS, Vault, Team Foundation Server (TFS), CMVC, AccuRev, and Star Team. More will be supported in the near future. Contact us if you have a specific request.

Currently we support MySQL, Oracle, Microsoft SQL Server, and an embedded database that can be used for trials (Hypersonic). Contact us if you have a specific request.

The web server is the only required component. Most users will install the client to make it easier to upload local files, especially with version control integration. We also have a Tray Notifier.

CodeCollaborator also comes with integrations for 3rd party tools such as Perforce and Eclipse. You can also access reports and the back-end data model using our XML-RPC Web Services or the command-line client.

Please see Moving Parts for details on all these components.

New features are driven by customer input, both informally (through tech support) and proactively (customer visits, round-table discussions). The following features are the kinds of things to expect in future versions of CodeCollaborator:

• Entry/Exit Criteria (Checklists): Checklist of things to be done before a review starts or before a review can be completed. Whole-review and per-file checklist items. File type-based checklists.
• Cross-Tool Reporting: Integrating reports with data from issue-tracking and version control. View efficiencies, kLOC rates, and injection rates across the entire development process.
• Cross-Platform Rich Client: Do anything from a cross-platform rich client for users who prefer the speed and interface of a local GUI client over the no-install convenience of a web-based interface.
• Off-Line Reviews: Ability review code when not connected to a network.
• Binary File Support: View diff's and comment on binary files like images, Microsoft Office documents, and PDF's.
• Reviewer Pools: Ability to make a rule like "two of these seven developers must review the code."
• Tighter Issue-Tracker Integration: Specific support for popular systems like TeamTrack, JIRA, FogBUGZ, and Mozilla.

Yes! Go to our secure sign-up form to get started. You will receive an e-mail whenever there is a major, minor, or maintenance release.

You can trial CodeCollaborator immediately by installing the components on your own machine. Just download the components and follow the installation instructions.

You can use the embedded database option in the installer to save time, or you can set up your database now. You can always switch to a real database later and take all your data with you.

The trial is only limited by time; you can use all the features of the software from the on-line downloads.

Please let us know if we can assist you in installing and configuring your trial software.

We are setting up servers for hosting trials right now. If you're interested, let us know so we can notify you when the trial server is available.

You may also download and install a free trial on your own machine.

Of course! Either watch the 40-minute demo movie from our website, or let us know when you're available and we'll set up an on-line demonstration. We can tailor the demonstration to your particular needs.

Yes! CodeCollaborator is FREE for open-source projects!

CodeCollaborator pricing is based on the number of human beings using the product. This can either be a floating license (based on number of users in a single 24-hour period) or a fixed-seat license (one license per user). Details on these plans can be found in the Owner's Manual.

All Smart Bear pricing is published on-line, so there are never any surprises.

There is no additional charge for the server itself, and there is no limit on the number of different servers you can have installed at once. There is no additional charge for the various component software that make up CodeCollaborator.

We always provide you with extra "grace" seats so you can temporarily exceed your licensed limit without disruption in service and without having to purchasing additional licenses. This applies both to fixed- and floating-seat licensing plans. This is described in detail in the Owner's Manual.

For a product installation we recommend at least a 2ghz processor, 1gb of RAM, and 80gb of hard drive space on a dedicated server. Typically the database is installed on the same machine as the web server; this is not required, but the connection to the database must be high-speed (e.g. at least 100mbps LAN).

Trial installations can easily share space with other server processes and are often installed on workstation machines.

If you are concerned about your usage scenario, contact us so we can give you a recommendation for your particular set-up.

Some shells don't work with the installer. Try running the installer like this instead:

> bash ./ccollab_server_4_0_835_unix.sh

Or, you may not have Java installed. If that's the case, please go to the following website and download and install the J2SE v1.5 JRE: http://java.sun.com/j2se/1.5.0/download.html

If you do have Java installed, our installer might not be finding it. To fix that problem, you can use the $INSTALL4J_JAVA_HOME_OVERRIDE environment variable or one of the standard java environment variables (like $JAVA_HOME or $JDK_HOME) to tell the installer where that path is, but if you have it installed in a standard place and we're not finding it please let us know — we'd like to fix the installer.

Yes! The installer for the server component allows you to select and configure LDAP authentication instead of the built-in database-based authentication. You can switch back and forth between these two methods if you need to.

Yes. CodeCollaborator runs under the Tomcat servlet, which can be configured to use SSL. Users will then connect to CodeCollaborator with an https: URL. For details, please refer to the Tomcat documentation on SSL.

There is no problem with replicating the front-end web servers that use a common database back-end. Your local system administrator is responsible for setting up the load-balancing and connection-failover system. There is no extra licensing fee for replicated installations.

This works because the web server stores all information and state in the database and caches "this user is logged in" with cookies in the user's browser (which is then transmitted to the web server on every connection). This even works with our client software and libraries because we use Web Services for all communication.

The database back-end can also be replicated. Consult the documentation for your particular database for details.

In general, when we release a new version of CodeCollaborator, the installation wizard should take you through all of the steps required to install the new version. However, we are frequently asked about what can be done to make the process go more smoothly or help things recover if something goes wrong. Here are some recommendations:

• Shut down: The installer is supposed to shut down the CodeCollaborator server before updating any of the files. However, very infrequently, for reasons we have not yet been able to diagnose, the server fails to shut down. Therefore, shutting down the server before upgrading is probably a good idea.
• Backups: As with all mission critical software, we recommend regular backups, but this becomes even more critical before an upgrade, as unfortunately sometimes things go wrong. In particular, we recommend backing up your database, the configuration directories, and the "content cache" where we store the files that are being reviewed.
  • Database backups. The most easy way to back up your database is to use the internal backup feature. Alternately you can use your database's native backup support. For example, to back up a MySQL database use the mysqldump utility: mysqldump --database {database name} -u {username} -p > collaborator_backup.sql This will create a file which can be used to restore your database should any database migration fail. Zip up the contents of the file and store it in a safe place.
  • Configuration files. All of the configuration that is not stored in the database resides in the {installation directory}/tomcat/conf directory. Make a zip or tar file of this directory and store it in a safe place.
  • Content Cache.The content cache directory is {installation directory}/tomcat/collaborator-content-cache. Make a zip or tar file of this directory and store it in a safe place.
• That's it: Run the installer and follow the steps in the wizard. The wizard is designed to prepopulate the wizard forms with your current configuration. You should not need to change anything unless you are intentionally moving to a new configuration.

When the wizard completes, your new CodeCollaborator Server should be up and running.

Yes. All our installers can be run from a command-line without a GUI so you can remotely install or upgrade developers' workstations.

With installs your script should also lay down a configuration file for each user that tells the client software the location of your CodeCollaborator server and the username/password to use to connect.

If you don't do this your users will not be able to use the client software until they set up that configuration. For upgrades this is not an issue.

The license code is entered into the CodeCollaborator server. Client software does not have to be specially licensed.

We have instructions with screenshots of how to install the license code.

Hiding behind Apache is useful for integrating with an existing web site. The simplest way to do it is to use the mod_proxy and mod_rewrite to have Apache proxy the web connection. Here's an example Apache configuration that hides a server running on port 5555 behind a virtual server called example.codecollab.com:

<VirtualHost *:80>
    ServerName example.codecollab.com
    RewriteEngine on
    RewriteRule ^/$ http://localhost:5555/index.jsp [P,L]
    RewriteRule ^/(.+)$ http://localhost:5555/$1 [P]
    ProxyPassReverse / http://localhost:5555/
</VirtualHost>

For details, see the Apache user's manual for mod_proxy and mod_rewrite.

The more complicated but more efficient way is to use the Tomcat/Apache connector module that lets Apache talk directly to a Tomcat server (which is what we use for our web server). See that link for details.

The changes also must be made to the server.xml located in <install-directory>/tomcat/conf. Specifically, the Connector element needs the following attributes:

proxyName:  The hostname of the proxy server.
proxyPort:  The port number to access on the proxy.

For example, using the VirtualHost definition above, the proxyName attribute would be set to example.codecollab.com and the proxyPort attribute would be set to 80.

For more information on configuring the Tomcat HTTP connector, see the Tomcat Server Configuration Reference.

You are encouraged to use the same user name for both CodeCollaborator and your version control system. This is not a requirement.

When user names are shared, developers don't have to remember yet another user name/password pair for code review. Also CodeCollaborator can automatically match up version control users with review users to pre-populate forms, create reports, and generally save time.

There are two ways people use checklists in CodeCollaborator:

1. Have a "checklist URL" custom field in the review summary. The review creator uses this to link in checklists from an intranet. The reviewers can click that link to pull up the checklist and either print it out or place it on their screen(s) in a visible location.
2. Upload the checklist(s) to the review as regular documents. The reviewers similarly can open those files on-screen and/or print them out.

Someday we hope to have a an integrated checklist system in CodeCollaborator, but meanwhile you still have the tools you need to have checklists.

Yes. The command-line client picks up Perforce configuration environment variables and uses user-settable configuration for defaults. The Perforce P4V/P4Win plug-in inherits Perforce configuration from the Perforce GUI.

No. Changes merged in from source control could potentially impact the validity of the author's changes by changing the surrounding logic. For this reason, it is important to review all the author's changes in the context of the merged code. CodeCollaborator gives reviewers the option of reviewing all the new changes since the previous upload including the merged changes or all of the author's changes against the post-merge base version from source control. Either view should provide enough context to understand the impact of the author's changes on the current version in source control. Reviewing only the author's changes since the last upload would not provide this context, so CodeCollaborator does not offer that view.

If you review code before you check it into Perforce, sometimes the Perforce changelist number is altered by the Perforce server during check-in. This happens when the changelist number would not be in time-order. For example:

1. Developer A starts working on local changelist 100
2. Developer B starts working on local changelist 101
3. Developer B checks in 101
4. Developer A checks in 100; but because this would result in changelist-order not being the same as time-order, Perforce renumbers 100 -> 102 and checks in as 102. Meanwhile changelist 100 "no longer exists" as far as Perforce is concerned.

If Developer A got a review of changelist 100, later in Perforce this would show up as 102.

See the CodeCollaborator manual for a workaround to this problem.

When uploading fixes after rework, it is recommended that you upload all changed files again, including files which were originally changed, but not changed during rework. CodeCollaborator will detect this and display the files as unchanged during rework.

To make things easier for reviewers to track, CodeCollaborator only displays the most recent changes and hides the rest under the link "Show previously-uploaded changelists". If in the latest upload there are no files in common with the previous upload, both are shown. This allows an author to upload additional changes which are relevant to a review, but were not included in the initial upload. If, however, there are files are in common between two sets of changes, only the most recent is displayed. This is because CodeCollaborator has no way to tell if the author reverted the files not included in the upload or just chose not to upload them. This is why the recommended approach is to upload all the files regardless of whether they were reworked.

For Perforce users this should not be an issue. Perforce changelists always contain all the changed files.

CodeCollaborator does not have date or time custom fields, but you can closely approximate a date or time by using regular expression validation of single line text fields. For dates, the following regular expression requires a date in the 20th or 21st century that is approximately valid (yes, it accpets 31 days each month):
(?:19|20)\d\d-(?:0[1-9]|1[012])-(?:0[1-9]|[12][0-9]|3[01])

The following regular expresion validates a time on a 24 hour clock:
(?:[01][0-9]|2[0-3]):[0-5][0-9]

The two could be combined to accept a date and time field. Be sure you set the description of the field to describe exactly the format you're looking for so that users do not have to parse the regular expression to know what to enter.

CodeCollaborator conversations are not inserted into the code as comments but rather stored and displayed in on the web site. However you can get a report of all these if you do want to export that data from Collaborator.

Typically you do not want the CodeCollaborator conversations in the code as comments because people ask questions, debate things, get confused, etc., and putting 100% of that in the code is probably even more confusing. Better is to update the comments in the code AFTER the review, once you decide what the "right thing" is, and when you can make that concise.

CodeCollaborator can be used to review code in any text-based programming language. For some programming languages it also supports syntax highlighting. Those languages are:

• ASP
• C
• C++
• C#
• CSS
• HTML
• Java
• Javascript
• JSP
• Perl
• PHP
• SGML
• Shell Scripts
• XML

Contact us if you are interested in syntax highlighting for a programming language not on this list.

If all clients are experiencing the problem, the issue is usually a server problem. Confirm that the CodeCollaborator server has been started and the database is online. Check the server logs in installation-directory/tomcat/logs/tomcat.log for error messages which might indicate why the server could not start. If another webserver is running on the same server machine, there may be a port conflict. Use the installer to configure the webserver to use another port. If you need assistance interpreting an error message you find in the log, send a copy of the log to Customer Support.

If the issue is confined to a single client, this usually means the problem is due to a misconfiguration of that client. Double check the URL you have configured to ensure that it refers to the CodeCollaborator server. Use a web browser on the client machine to access CodeCollaborator to confirm that the network is working between the client and server. If the website is also unavailable, there may be a network issue preventing the client from accessing the server.

Yes. In addition to tracking access, this is a good way to help diagnose connection issues. To configure basic access logging, add the following to installation-directory/tomcat/conf/Catalina/localhost/ROOT.xml:

<Valve className="org.apache.catalina.valves.AccessLogValve" pattern="common" resolveHosts="false" />

After changing the configuration, you will need to restart the CodeCollaborator server. After the restart, the access log will appear in installation-directory/tomcat/logs.

Please see that section in our Owner's Manual.