CodeCollaborator Frequently Asked Questions

Currently we support: CVS, Git, Mercurial, Perforce, Subversion, Vault, AccuRev, CMVC, MKS, Rational ClearCase, Rational Synergy, Rational Team Concert, StarTeam, Surround, Team Foundation Server, Visual Source Safe. 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).

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 command-line client.

Please see Components for details on all of these components.

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 also sign up for our periodic newsletter.

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 in the online downloads.

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

Yes! Try out hosted Code Collaborator running on our public server.

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

Of course! Either watch the 5-minute demo or the 40-minute demo from our website, or let us know when you're available and we'll set up a personal online demonstration. We can tailor the demonstration to your particular needs. We also do open webinar demos regularly -- you can view the schedule and sign up here.

Yes! CodeCollaborator is FREE for open-source projects!

CodeCollaborator pricing is based on the number of human beings using the product. You can either get 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 online, 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 makes 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 courtesy, described in detail in the Owner's Manual, applies both to fixed- and floating-seat licensing plans.

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

For permanent product installations, we recommend at least dual XEON 3.5GHz processors, 2GB of RAM, 10,000 RPM hard drives (preferably SCSI) and 100GB of hard drive space on a dedicated server. Typically the database is installed on the same machine as the web server. While this configuration is not required, the connection to the database must be high-speed (e.g. at least 100mbps LAN).

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

You have several possible solutions here:

• 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 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 configuration 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 are then transmitted to the web server on every connection). This structure even works with our client software 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 step 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 easiest 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 utility creates a file that 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 information 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 pre-populate 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 this configuration file is not created, your users will not be able to use the client software until they set up that configuration. For upgrades, it's not an issue if the configuration file is not created.

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, although it's not required.

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 URL 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 of 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 re-numbering 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 action 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 received a review of changelist 100, then later in Perforce, this review 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 that were originally changed but not changed during rework. CodeCollaborator will detect this status 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 visibily allows an author to upload additional changes that 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. CodeCollaborator behaves this way because it has no way to tell if the author reverted the files not included in the upload or just chose not to upload them. Thus, the recommended approach is to upload all the files regardless of whether they were reworked.

Perforce users won't experience this issue of files not showing up after rework / upload, because 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 accepts 31 days each month):
(?:19|20)\d\d-(?:0[1-9]|1[012])-(?:0[1-9]|[12][0-9]|3[01])

The following regular expression 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 on the web site. However you can get a report of all comments 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. It's better to update the comments in the code AFTER the review, once you decide what the "right thing" is and can make the comments concise.

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

• ASP
• C
• C++
• C#
• CSS
• HTML
• Java
• Javascript
• JSP
• Perl
• PHP
• Python
• Ruby
• 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 that 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, it 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. And in addition to tracking access, access logs provide 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 need to restart the CodeCollaborator server. After the restart, the access log appears in installation-directory/tomcat/logs.

Please see that section in our Owner's Manual.