CodeCollaborator Frequently Asked Questions

Currently we support Perforce, ClearCase, SourceSafe, Subversion (SVN), CVS, Vault, and PVCS. 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 command-line client to make it easier to upload local files, especially with version control integration. We also have a Windows GUI client.

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:

• Rule-Based Workflow: Automatically adjust workflow based on development groups, software code sets, and geographic location. For example, you might have rules where developers get reviewed by team-leads, or where the owners of code modules are always invited to the review.
• RSS Feeds: Receive notifications by RSS feed instead of just by e-mail. Configure how and when to receive notifications of different types.
• 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 FAT Client: Do anything from a cross-platform FAT 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!

You will use CodeCollaborator from a server we host here at Smart Bear. The reasons we offer this free server only as a hosted service are: (1) reduced support costs for us by hosting only the latest stable release; (2) usage information that helps us understand how people use the software; (3) acts as a continuous scalability test that we can monitor; (4) allows us to track the number of projects, users, files, etc. which we can then brag about.

This service should be starting in late Jan or early Feb 2007. Let us know if you're interested so we can drop you a line when it's ready.

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 do offer Smart Bear Gold Support for an additional fee. Please see that link for details on what this entails.

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.

Yes, we can host the CodeCollaborator server for you, saving you the hassle of server administration, backup, and security. This is especially useful for distributed teams where a central server is difficult to maintain.

Contact us for details.

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.

We can also host your installation on our servers, either for trials or for production use.

For production installations serving 50 users or more, or for distributed installations, 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_1_0_345_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. To back up the 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. As of CodeCollaborator version 1.0 build 400, the content cache directory is {installation directory}/tomcat/collaborator-content-cache. In earlier versions, the content cache resided at {installation directory}/tomcat/webapps/ccollab/content-cache. Locate your content cache and make a zip or tar file of it 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.

For Code Collaborator 2.0 and later, 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 Code Collaborator 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.

In Code Reviewer the concept of the "checklist" is built-in. You can define checklist items -- one set for the entire program, no matter what type of file you are looking at. The checklist is displayed during the review, and the reviewer must tick off each box before the review can be complete.

In Code Collaborator, you can still have checklists, they're just not built into the system. There are two ways people do this:

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.

The problems with the Code Reviewer method are:

1. Different file types need different checklists. E.g. Java source code, C++ makefiles, and requirements documents need completely different checklist items.
2. Actually ticking off each box is tedious.
3. How does the list fit on the screen with the rest of the interface? Depends on your monitors, whether you like print-outs, etc..

Someday we hope to have a good answer to these problems with an integrated system in Code Collaborator, 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.

Right now the Windows GUI Client and the Command-Line Client are on two separate code-bases. We hope to remedy this problem over the next few months. This will solve the configuration and multiple installer issues.

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.

We will be "fixing" this in a future version of CodeCollaborator with a Perforce server-side trigger that will update the CodeCollaborator database when this happens.

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.

CodeCollaborator uses HTTP to contact our license server at http://licensing.codecollab.com. If your network requires a proxy to access websites, you will need to configure CodeCollaborator to use an HTTP proxy. To enable HTTP proxy, add the following lines to the ccollab-server.vmoptions file in the server installation directory:

-Dhttp.proxyHost=proxy_hostname
-Dhttp.proxyPort=proxy_port
-Dhttp.proxySet=true


Some newer firewalls have been known to create additional problems with services, such as CodeCollaborator accessing the Internet via HTTP. For instance, some firewalls periodically return a web page to verify that a human is actually using a browser. If this is the case, contact your network administrator to request an exemption from this policy for CodeCollaborator.

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/context.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.