If you need to re-integrate that erroneously integrated change into some other cycle, open 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.
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 in your CVS status files. Steps to try in such situation:
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.
This is caused by a bug in ViewCVS. Ask your system administrator to apply the patch available from supporting files page in Changelogic.
The common symptom of this problem is that integration directory appears in working directory although you have specified different path in your devweb-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 java.util.Properties class.
The build script doesn't currently check whether there are actual conflicts or not, it just cancels and gives you possibility to find out. This default message is replaced in newer versions and actually you can configure it by yourself in file devweb-project.properties from property called “devweb.integration.prepare.stop.message”. 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.
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 ext protocol, any other protocol should be fine though.
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.
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 CVS 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 avoid it, but we strongly recommend not to do it. 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. 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.
You must do ant -f devweb-build.xml upload_diff or use this target's project based mapping. You can find the target's name by typing ant -projecthelp or just ant -p.
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 devweb-personal.properties file and CVSROOT specified in environment variable do match. If they don't, make them match by putting the same CVSROOT to devweb-personal.properties file. If you do it the other way, you might need relogin 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 changeing 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.
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 microchange 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.
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.
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 uses CVS for its version control functionality.
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:
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.
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 “Functinality 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).
The linking words are: task, change, testcase, comment, run, attachment, adjustment and bug followed by space and ID. On task detail form you can also see incoming references under section “References to current task” if there are any.
The keyword version does not link because version numbers are not unique.