If you use Changelogic version 1.x, please follow the link: Changelogic V-1.x FAQ
If You encounter a problem that You cannot understand or resolve yourself (and which is not covered in current FAQ document), please don't hesitate to contact Changelogic's support at . Be sure to attach the relevant changelogic.log log file (from directory .changelogic-rt) to your e-mail.
Client writes log about its activity. All log messages are written to Client's log file changelogic.log under the .changelogic-rt directory of the project directory, log messages that might be of interest to end user (log levels INFO and above) are additionally written to the system console or Eclipse console.
The file changelogic.log contains log messages for the current day only. In the end of the day the file changelogic.log is automatically renamed to date suffix in format YYYY-MM-DD. For example, to see what you did on april the 1st last year, please look up the file changelogic.log.2009–04–01.
.changelogic-rt is the runtime directory for Changelogic's client. It is used for storing log files and required libraries. Its subdirectory checkout is the default location for performing temporary VCS checkouts for base version updates, integrations etc.
If you delete this directory either intentionally or by accident, it will be recreated automatically. So, you better ignore its existence and tell your VCS to do the same (the dot in front of its name makes it “hidden” if you happen to be using Unix-like filesystem).
If you get this error message, you should upgrade your Ant installation. Ant version 1.6.3 or newer (except 1.8.0) should be fine. If you already have a newer Ant, make sure that the weblogic.jar of WLS9 is not in your classpath – it contains classes of Ant 1.6.2.
When there are no trusted certificates available, a javax.net.ssl.SSLHandshakeException (No trusted certificate found or unable to find valid certification path to requested target) is thrown when Changelogic attempts to contact with HTTPS URLs. The problem can be solved by installing an appropriate certificate.
This has been successfully tested with Eclipse 3.2 on Java 5.0 and 6.0 VMs. Reportedly, there could be problems with Java 1.4(.2) VMs.
The most common reason for this error message to come up is when the HTTP requests have been configured to be passed through a proxy and you are using “localhost” as the server name in client configuration (setting cl.rooturl). Please edit the client configuration to use a public name for the server.
This might happen when a newer version of Changelogic attempts to resume the suspended process from the serialized-commands file written by an older version of Changelogic. Currently, there are no automated recovery means available.
You may issue the command ant changelogic_reset from the command-line, or select the “Reset” menu item from Eclipse's plugin menu to discard the unusable suspended process for good.
A common symptom of this problem is that integration directory is created in working directory although you have specified different path in your changelogic-personal.properties file. The solution is to use forward slashes (/) or double backslashes (\\) in path. This situation is caused by conventions of a “.properties” file as described in the API of java.util.Properties class.
The client doesn't currently check whether there are actual conflicts or not, it just cancels and gives you possibility to find out. You can edit the message in file changelogic-project.properties through property called “cl.integration.pauseMessage”. Commenting out that line makes build script automatically continue with integration; downside is that when you have multiple conflicts, they will be reported one by one on every build script run and possibly after much processing may already have been performed;this may be very annoying. Actual conflicts are indicated by message “rcsmerge: warning: conflicts during merge” in merge log.
Go to the detail form of the change and find out the branch tag. Do checkout/update with that branch tag; you can get the update command from change's form too. You can switch changes the same way.
Changelogic does not currently provide functionality for deployment, but you should go to detail form of the version you want to deploy, get the VCS tag for that version and do checkout/update to that version. You can get the command for update from version's form. Then use project specific targets for build and deploy.
We cannot prevent it, but we strongly recommend not to do it. However, you may run ant edit when a change is waiting for review or integration, and then edit your change as usually.
If you commit after or during review, this code will not be available for review and will not show up in version differences although this code is propagated to mainline with integration. Please note that in future versions Changelogic may ignore such edits during integration.
If you commit during or after integration, this code will not be propagated further to any version or cycle, it will stay only in that change's branch, thus there is no use in committing after integration has started.
Use ant upload_diff. Note that in order to generate diff, your files will be committed to repository first.
You can find the target names by typing ant -projecthelp or just ant -p. Sometimes target descriptions are left out, use ant -projecthelp -verbose (or ant -p -v) in that case.
If the other change has been integrated, you should update the base version of your change to include the other change. If the other change is still being developed, you should replan your change to be a subchange of the other change and then do a base version update. If the development of the other change has already been finished, but it has not been integrated yet, you should wait until it reaches one of those two states. It is dangerous to manually merge another change into yours or mark the change branch, as Changelogic will not take this into account when integrating or updating base version your change and severe merge conflicts or code loss may occur as a result.
Your code is still in the previous change you edited; since that change has not been integrated yet, the code is not available in other changes. The code will be available for other changes after it has been integrated.
Then you could tell Changelogic to branch off your change as a microchange of that change. To do this, set the “planned macrochange” of your change to the change you want to include code from, then start development of your change (or perform a base update, if you had already started development earlier). After that, replan your new change where it should actually be planned, and avoid base update until the needed change gets integrated.
Just run the command ant edit when your change is awaiting review or integration. You may also ask the reviewer to fail the review.
You can mark the integration failed through the details page of the change in the web interface.
To add new files to VCS repository one should run cvs add filename1, filename2 ... or svn add filename1, filename2 .... For more detailed information see Editing code topic.
If your java.exe crashes with this message during svn checkout, you should download and install latest openssl library from http://www.slproweb.com/products/Win32OpenSSL.html
Make sure there is no trailing slash in your cl.vcs.repository setting and it matches exactly the URL you checked your code out from.
Make sure your working directory has been checked out from either a branch or tag, not from trunk. You can use svn switch to fix this problem.
If that was not the case, make sure your cl.vcs.repostiry setting contains only the path BEFORE the repository path specified in project details (i.e. does not contain project folder).
Some people have had problems with the Changelogic client entering infinite recursive loop when Changelogic tries to run some ant target in integration or base version update directory after merge. Sometimes it is preceded by error messages about missing “cl.user”:
[updatebase] Execution failed because of com.changelogic.client.MissingPropertyException: Cannot find property cl.user
[updatebase] Please verify the changelogic-personal.properties file
This is caused by a bug in Ant 1.8.0 – https://issues.apache.org/bugzilla/show_bug.cgi?id=48876
Please upgrade to Ant 1.8.1 or newer if you have such problems.
Yes, as long as your project is a bunch of files hosted in version control (eg. database objects not mirrored as files can not be managed using Changelogic). Changelogic client does not care what technologies your source files are written for (okay, binary formats are not automatically mergeable by VCS and may thus cause problems if same file has to be changed often). And if you can build/test your project from command line, you can declare Ant targets <exec> those commands during integration.
If you need to re-integrate that erroneously integrated change into another cycle, add a new change and merge forward diff into that change, e.g. svn merge http://svn.example.com/myproject/tags/ver-2_13_4_18 http://svn.example.com/myproject/tags/ver-2_13_4_19 – note that the URL of the earlier version comes first this time.
If your change edited modules, the undo change should edit the same modules, and similar svn commands should be run once in every module.
Make sure your environment variable APR_ICONV_PATH points to directory iconv under your Subversion client installation directory, e.g. C:\Program Files\Subversion\iconv
This seems to be a timeout issue in some SVN 1.4.x clients. Usually the operation succeeds upon retry; upgrading the SVN client is recommended.
This is likely to appear after your repository password has changed. Just try doing the same action from command line using SVN client so it could ask you for new password.
Read more about Subversion credentials caching.
There are several potential reasons that could trigger this error message.
It seems that Subversion 1.4.6 sometimes composes an invalid HTTP request. You might want to try using different protocol (svn, https, svn+ssh etc) or upgrading your SVN client.
An additional symptom for this problem: Apache error_log in SVN server shows «XML Parser Error: XML parser error code: xml declaration not at start of external entity (17)".
You might have a device on your network that does not support TCP scaling factor communication, also known as TCP auto-tuning in Windows Vista / Windows 7. Use command netsh interface tcp set global autotuninglevel=disabled to disable TCP auto-tuning.
More info here: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx
A disk at Subversion server is full. Contact an administrator for that server.
If you need to re-integrate that erroneously integrated change into another cycle, add a new change and merge forward diff into that change: cvs up -j ver-y_y_y_y -j ver-x_x_x_x, where tags are defined as previously stated.
If your change edited modules, the undo change should edit the same modules, and similar cvs commands should be run once in every module.
A common symptom of this problem is error message like this: “move away foobar.txt, it is in the way”. It's usually caused by absence of entries for these files or their directories in your CVS statu files. Steps to try in such situation (remember to back up the affected files first):
Quite frequently this problem is caused by files or directories that exist in working directory before performing checkout from CVS and have the same names as the files in CVS. This might happen if some script prepares your working directory by creating some directories, or if you delete some folders/files including the special folder “CVS” to clean your working copy.
Please check that you don't have any files or directories named CVS* or cvs* in the directory one level up from working directory. CVS client will consider these as directories where CVS status files are ought to reside, but it will not find any status files there. Solution is to move away or rename that directory.
You shouldn't mix different clients and servers, use CVS client when communicating with CVS server. Although CVSNT client can communicate to CVS most of the time, we cannot guarantee there won't be any problems as we've encountered them many times in practice.
You can find out what version on CVS client you are using by typing cvs -v on command line. You can download CVS client from supporting files page in Changelogic.
It's caused by design of CVS. Changelogic operates exclusively on branches; files available only in branches are placed to Attic in CVS. Don't worry, checkout will place them in right location.
Changelogic is currently tested only with pserver protocol and from local machine. Changelogic is known to have problems with Eclipse proprietary protocol “:extssh:". Any protocol supported by command-line CVS client should be fine.
Yes, you can use tunnel. All communication with CVS is done only on client's side through build script, Changelogic's web interface does not directly access CVS, thus the machine, where the web interface is hosted, does not even need to see CVS server.
The whole error message looks probably something like this:
[cvs] PAM authenticate error: Authentication service cannot retrieve authentication info.
[cvs] cvs <operation>: authorization failed: server cvs.local.net rejected access to /var/cvs for user <you username>
[cvs] cvs <operation>: used empty password; try “cvs login” with a real password
To solve this problem, check if the CVSROOT specified in changelogic-personal.properties file and CVSROOT specified in environment variable do match. If they don't, make them match by putting the same CVSROOT to changelogic-personal.properties file. If you do it the other way, you might need re-login or even new checkout, because CVSROOT from environment variable is saved in working directory too.
If you really changed your password lately, try to remove every .cvspass file you can find – it's not specified in CVS manual where the client puts this file by default and then login again. It might also happen that after changing your password you log in with IDE's built-in CVS client and it writes line endings to the cvspass file different that the command line CVS client expects.
You may also try to set the environment variable CVS_PASSFILE, logout, login and try the operation that initially failed again.
This error appears when some process (e.g. your GUI or Ant) has locked the mentioned file, so it cannot be updated from repository. In some rare cases, you could also be lacking permissions to write the file. First, try to identify and terminate the offending process. If the problem persists, it could be that your build script locks the file, e.g. by using the file within some classpath. In that case, rewrite the build script; e.g. you could first make a temporary copy of the file and use that copy within the classpath. If this was not the case or doesn't help, some system process could have locked the file; try rebooting the system.
If you get errors like
cvs server: failed to create lock directory for `/home/cvsroot' (/home/cvsroot/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository `/home/cvsroot'
cvs [server aborted]: read lock failed – giving up
then the reason could be that you have checked out some directories using different username or CVSROOT than the rest.
We recommend you to back up and delete the offending directories from your local checkout.
This error message may appear when you attempt to operate in a working copy hosted under Unix-like environment that has been checked out from under Windows (via a Samba share, for example). The metafiles contain Windows-style line breaks, thus Unix client is unable to read them. Perform all your CVS operations under the same operating system.
If you intend to use Eclipse built-in CVS client, then the answer is no. Eclipse client has another means of storing local metadata that are not compatible with regular client used by Changelogic. For command-line client, safe operations are listed below.
You may safely perform checkouts and update your working directory. You should avoid adding or modifying tags/branches with names that are meaningful to Changelogic, since the Changelogic keeps a record about its tags in your repository and will not be aware of such manipulations; thus integration, base version update or other features may not work as expected. Committing to CVS should preferably be done using build script to cut down chances of inadvertent committing into wrong change. Manual merging within Changelogic branches accompanies high risk of code loss later and should be avoided unless specifically advised by Changelogic support facilities. When committing make sure you are committing into the correct change (you should never commit into a main branch of Changelogic).
VCS is a common acronym for version control systems in general. There are many different VCS implementations, and CVS (Concurrent Versions System) is the most popular one, although there are many others. Changelogic is able to use CVS or Subversion for its version control functionality.
This error occurs because the CVS executable (cvs.exe) is either not found in the execution path, or the path to it contains spaces (e.g. it has been placed under Program Files). Make sure that the CVS client executable is in some directory on your path that does not contain any spaces in its full name.
This happens when somebody has committed a text file created or modified in Windows via a Unix-like system, e.g. Linux or Cygwin. On Unix like systems, a standard line separator is byte 0x0A; on Windows, it is two bytes: 0x0D 0x0A. When committing from Windows, CVS automatically removes the 0x0D byte before storing the revision, and adds 0x0D byte before each 0x0A whenever a text file is checked out. When committing a file on Unix-like systems, the 0x0D symbols are not removed because they are assumed to be part of text content, not part of line separator; but when checking out the same file on Windows, 0x0D is still added in front of each 0x0A, resulting in double 0x0D bytes: 0x0D 0x0D 0x0A.
Such files are a real nuisance because fixing them means changing each row in the file, thus creating a huge conflict with every other parallel change that happens to modify the same file. Therefore it is best to avoid editing text files on a platform having different line separator from the platform where these files are committed to CVS.
However, when the trouble is already present, the line separators should be fixed in a change that gets quickly integrated (starting from the oldest branch that must be still supported), and no one should edit the older variants of these files without doing a base update first.
If you get error like
cvs commit: failed to create lock directory for `/home/cvsroot/foo/bar/#cvs.lock): No such file or directory
then the reason might be that you added several directories nested within each other using one CVS command. Unfortunately there is a bug in CVS and such adding does not work – the directories are not created on server.
A solution would be to delete metafile directories named “CVS” in those nested directories and add them again one by one along with the files in them.
This error happens when a directory does not contain metafiles (the “CVS” directory) created by CVS during checkout. This seems to happen in some cases when CVSNT client is used to access a server running CVS. Please try using the latest client from http://ftp.gnu.org/non-gnu/cvs/binary/stable/x86-woe/ instead. Please note that the working directory is already screwed, you should perform a new checkout. If there is some uncommited valuable stuff in the ruined working directory, you may heal it by copying missing metafile directories from another checkout of the same branch. Please study diffs before commiting – a mismatching revision number in a metafile could cause you to wipe away edits from some other commits.
This error occurs when your CVS command should remove some directory (e.g. cvs update -P), but the directory is currently in use by some other process (e.g. it is current working directory for some command line window or editor) and thus cannot be removed.
Depending on your cvs version, cvs checkout -r tag -D date module or cvs checkout -r tag:date module should work. In newer 1.12.x versions, cvs update -r tag:date also might work.
Note that this approach is not very suitable for tags, because tagging chronology is not kept by CVS and the results are usually unexpected.
You can do that starting from versions 1.30.x.x of Changelogic. Navigate to the page of the change and click “Reopen”.
Click “Add a new functionality stage” in section “Functionality stages” on the details page of your project.
Versions are only formed by integrating changes. You can not add a new version via web interface.
No, code written in chages that are integrated only to newer cycle will not be available in older cycle just by replanning. During integration only diff between change's base version and current state will be applied to the cycle's last version, where the change is being integrated. Nevertheless, backplanning introduces some risks, so it's best to do base version update (actually downgrade) before ending development, because, for example, the code may depend on some other code that is available only in newer cycle (from where we got base version at first).
This is caused by a bug in ViewVC. Ask your system administrator to apply the patch available from supporting files page in Changelogic.
Enter "" (two double-quotes) into the text filter.
Enclose the search phrase in double-quotes.
The linking words are: task, change, testcase, comment, run, attachment, adjustment, incident and bug followed by space and ID. The keyword version does not turn into a link because version numbers are not unique between different projects.
On task detail form you can also see incoming references under section “References to current task” if there are any.
Use the section “Actor” in task list filter. Enter you name as the Actor, click the section open and check the box that says “Resolver”.
The black ones are new ones or have some comments that you have not yet read.
Comment field is in the second section («Actions and history») on the form.
CSV export is available since versions 2.10.x. Use Task > Search > Export.
In earlier versions, the data can be copied via some text editor. We've had best results using Google Chrome as the browser. With other browsers, you might want to turn off “tooltips” under your Changelogic settings to keep them from appearing into copied data.
If you get errors similar to these:
File 'NONEXISTENT/charsets/?.conf' not found (Errcode: 2)
Character set '#33' is not a compiled character set and is not specified in the 'NONEXISTENT/charsets/Index' file
File 'NONEXISTENT/charsets/?.conf' not found (Errcode: 2)
Character set '#33' is not a compiled character set and is not specified in the 'NONEXISTENT/charsets/Index' file
then PHP's MySQL interface is not reaching MySQL character set definitions. There are some possible solutions:
When logged in, click on your name in the upper right corner and select “Notifications” from the appearing menu. You can then choose which events in which projects are you interested in and whether you want to receive notifications by e-mail and/or RSS newsfeeds.