Salient Soft

I received this error whilst performing a commit via Eclipse:-

The server reported an error while performing the "cvs add" command. cvs server: xxx added independently by second party

The error related to some test database scripts in the project. I searched for solutions to this, and found some comments about tagging the files as merged, but this was not really any help.

In the end, I examined the files using TortoiseCVS, and noted that the offending files were not flagged as being under source control – they did not have any icon decoration on them.

In the end the following steps solved the problem:-

1. I made sure I had copies of them elsewhere, and then deleted them from the (TortoiseCVS managed) directory under the eclipse project.
2. I then did an Update with TortoiseCVS – this reloaded the latest versions from CVS, and this time they were correctly icon-decorated as managed.
3. I then copied the new versions in to replace these. When I did this, the new versions were correctly decorated in red as updated versions but known to CVS/Tortoise.
4. I then did a commit with Eclipse, and this now proceeded without error.
5. Finally to be safe, I did a file compare to check that the correct latest versions were in place.

This solved the problem. It appeared that somehow I had lost the required CVS metadata such that the files did not appear to be CVS managed. Tortoise was very helpful here – if you see files with no icon decoration, this is immediately suspicious.

No Comments »

This post details the installation I use for CVS based source control, together with some usage points and gotchas I came across. My preferred installation consists of the Eclipse CVS plugin and TortoiseCVS on the client side. This gives the flexibility of CVS access both inside and outside Eclipse. In my experience both CVS clients coexist well, and changes in one are immediately  reflected correctly in the other as would be expected. My server side consists of CVSNT running on a separate repository server.

I have broken this tutorial down into linked sub-posts as it was becoming too monolithic and covered multiple topics. The steps are as follows :-

1/ Server Installation using CVSNT

3/ Client Installation, Configuration and usage notes- TortoiseCVS

4/ Client Installation, Configuration and Usage notes – Eclipse CVS Plugin

5/ Branching and Merging in Eclipse CVS and TortoiseCVS

No Comments »

To set this up, I gave the designated user full permissions on the repository root, with full inheritance to all subfolders and files. I also made the user the owner, but this may not have been required. I also gave full access to the designated temp directory (the one set up in CVSNT admin) to this user.

When I tried to use a dedicated ‘limited’ (non administrator) account under windows XP pro I received the following error when I tried a checkout of CVSROOT :-

CVSNT user does not have read access to CVSROOT

Initially I thought this was an issue blocking all checkouts, as with the user set as an administrator, this checkout is allowed. However, the error only occurs on CVSROOT – all other operations on other modules appear to work normally. As CVSROOT is created internally by CVSNT as part of the repository, we should not be checking it out anyway so this should not be a problem.

Setting up this way minimises security issues especially when saving an explicit password parameter in TortoiseCVS (with the pserver protocol) to get around the lack of password caching.

The CVSNT admin utility, under the Server Settings tab, allows an anonymous user to be specified, allowing anonymous access from the clients. I did test this briefly, but could not get it to play ball with TortoiseCVS – tortoise always seemed to get demands for a password and gave an error if I tried anonymous access. I googled for answers to no avail – no info was available on this setting. I combed the documentation but this all seems to be aimed at the command line interface to CVS rather than the GUI control panel interface used in CVSNT.

My final solution therefore was to use an explicit limited (non administrator) account, which works fine.

No Comments »

cvslock.exe sometimes crashes with the following pair of event log messages :-

1. Failed to bind listening socket: Only one usage of each socket address (protocol/network address/port) is normally permitted.
2. Faulting application cvslock.exe, version 0.0.0.0, faulting module advapi32.dll…

Initially I thought this was due to not adding it as a firewall/antivirus exception, but the error still appears to happen the first time a repository is created and brought up/reconfigured. The 2 errors appear to be related – the socket error may be due to cvslock being started twice in error (indeed, this may be the cause of the other error too.)

Once the repository configuration is up and stable, the error does not seem to occur.

When the error occurs, a systray icon for cvslock appears, and selecting the debug listing menu option for the tray icon displays the error “no ipv6 address found for host” in a command window.

I tried stopping the services, creating a new repository (which succeeds), and then starting the services. The cvslock service refuses to start, and the tray icon appears as above. After a few seconds, the tray icon disappears, and the service can be started as normal.

This does appear to be a cvslock issue related to new repository creation. As the workaround is straightforward, and operation appears stable after that, the bug appears to be a minor one.

No Comments »

Branching allows version histories of a CVS module to proceed in parallel, by branching from an earlier version in the repository. This typically arises when a new release is under development in the repository (or has been released) and bug fix changes are needed to an older version without affecting the new release. A branch would be made at the older version and the bug fixes placed on the branch. A client (Eclipse or TortoiseCVS) can pick the branch to work with, and the local files are updated to reflect that branch.

1. To create a branch in Eclipse, select Team/Branch… from the context menu for the project
2. To create a branch in TortoiseCVS, select CVS/Branch… from the context menu.
3. To select a branch in TortoiseCVS, you do an Update Special and pick the branch to switch to.
4. To select a branch in Eclipse, you do Team/Switch to another branch or version

When Branching, you should normally branch a complete module not just a file. If you just branch a file in eclipse, Eclipse gives you a warning that you are mixing tags within a project. Tortoise does not give you a similar warning however. See here for the internals of branching in CVS. It seems that whilst internally it is done per file due to historical coding reasons, it should ideally be ‘grouped’ as CVS does group files.

If you branch by mistake, you cannot delete it – just leave it unused in the repository.

You can merge changes back into a branch from another branch with both these clients. In both cases, you should have the target branch (which will often be the head) as the current loaded one. You then pick the branch to be merged into it.

1. To merge a branch into the current branch in Eclipse, use Team/Merge
2. To merge a branch into the current branch in TortoiseCVS, use CVS/Merge

No Comments »

Eclipse comes with a CVS plugin pre-installed. To connect to a repository, open the CVS Repositories view and add one via new from the context menu. The Eclipse CVS client is a pure Java one with a more limited set of protocols than the full set allowed by CVSNT – I use the pserver protocol, which encrypts passwords but not any other traffic. This is fine for a trusted internal development network behind a firewall. Eclipse does allow password caching and asks for secret questions for password recovery.

Note that if you get timeouts trying to connect to your repository and you are using CVSNT, make sure that you have excluded cvsservice.exe and cvslock.exe fully from both your Antivirus software on the server and the Windows Firewall on the server. In my case I used the default TCP ports in all cases on both clients and the server without problems once this had been done.

By default, my icons in the package/project explorers did not show when a file was dirty, i.e. when I had made local changes to a checked out file (Eclipse terms this an outgoing change). I could see the changes in the Team Synchronization view, which is useful as it isolates your changes from all the unchanged files, and allows filtering on the type of changes (outgoing, incoming, both, change conflicts). However, it is highly desirable to have the simple feature of tagging the icons on the dirty files, and this did not work even though I strongly suspected that such a feature would be available. It turned out that this labelling of the icons is enabled in the preferences.  Select Window/Preferences, then select Team/CVS/Label Decorations in the left pane, then the Icon Decorations tab, and select all the options. In my case, Outgoing changes was not selected, so local changes to a file in Eclipse did not make it show up as ‘dirty’ on the explorer icon. Selecting the option fixed the problem.

Usage Points

1. Most of the CVS options are under the Team submenu in the package explorer context menu.
2. However, one exception which can catch the unwary – to revert to checked out version – use Replace With and Latest from HEAD or Another Branch or Version on the explorer context menu
   i.e. this command is not under the TEAM submenu.
3. The CVS Repositories view is useful for browsing the server side repository including all the branches and files.
4. The Team Synchronization view is useful for viewing your changes – incoming, outgoing, and change conflicts

No Comments »

Download and install TortoiseCVS from here. Note that the release notes for version 1.10.10 state that 64-bit versions of Windows are supported. My installation runs fine on Windows 7 64-bit.

Except for the main preferences screen, all of Tortoise CVS is accessed via Windows Explorer context menus. Note that this also works within the file open dialogs of applications.

Connecting to the server is done from the CVS/Checkout… menu. In the left pane of the resulting dialog, you select the protocol, protocol parameters, the server, and the repository folder. In the case of my Java repository above, this will be /Java. Note that you do not need to tell the client the server side path of the repository root.

Tortoise does not cache passwords for access to the CVS server, so you have to enter it for the first time in each session. You can however add custom switches for the connection protocol, which may allow a password to be specified. Note that this is therefore not encrypted! You will probably want a dedicated low privilege account for CVS access if you do this, and in fact this is recommended anyway  – see here for details on how to set this up.

For the pserver protocol, you can add password=mypassword to the Protocol Parameters box in the checkout dialog.
The settings in this dialog are remembered for the next time you use it. If you access multiple replositories, they are remembered and may be selected in the list box at the top.

You do not want Tortoise control on all your explorer folders, as this can slow explorer down and clutter up the context menus when you don’t want it. Use the advanced tab in the preferences dialog to include/exclude folder trees from Tortoise control. Note that if you add a folder tree to include, all others are excluded – see this post here. You can also exclude network shares etc. (done by default).

Usage Points

1. When checking out, you pick a module name in the RHS pane. You can browse for/refresh the module list first.
2. After checkout, you get a subfolder for the module tree, which contains a cvs folder which contains metadata and is managed by Tortoise.
3. If you do a ‘wild’ checkout you will end up checking out CVSROOT which you don’t need – this can be deleted.
4. You can tag a file or group of files/module etc. to indicate a version, then check this out later using the tag. Note that internally, CVS uses a an “n.n” style internal version number starting at “1.1” for a file.

No Comments »

This post details the setup of a repository server on a Windows based PC.

Download and install the CSVNT server here.
Make sure you pick the Windows Server software and not the “client trial”.
If you show all downloads you need to pick a server OS, not a client OS like Windows XP, even if installing on Windows XP Pro like I was. (You cannot install on XP home at all  – you must have simple file sharing turned off and Windows XP Home cannot do this). In my case, simple file sharing was off as I had already turned off ForceGuest, see here.
You can pick a specific account for access, or use the client account  – I presume the user/password must also match the server if you are in a workgroup rather than a domain but I did not test this. My installation was in a Workgroup with a specific account on the server PC. Note that you should run CVSNT under an account on the server with the minimum of privilege, rather than an administrator account. See here for details on how to do this.

The server runs 2 services – CVSNT Dispatch Service and CVSNT Locking Service, which both need to autostart (this is done by default). The server administration is via a control panel utility which is also available via the start menus.

Ensure that Simple File Sharing is turned off.
Make sure that you exclude cvsservice.exe and cvslock.exe in both the Windows Firewall and any Antivirus software.
In my case failure to do this caused 2 problems :-

1. cvslock.exe crashed soon after startup
2. The repository was not visible at all from the client side (in Eclipse) and would not connect – connection timeouts occurred.

You can run multiple repositories from a CVSNT server. In my case I am using a common root – “D:\CVS Repositories” and a subfolder for each respository underneath. My Java repository is named /Java and is similarly connected this way on the client. Its Root is therefore defined as D:\CVS Repositories\Java.

Connecting to the server

In all cases I use the pserver protocol – the Eclipse plugin does not support many protocols natively and pserver is the most common. I use the same protocol for Tortoise..  The server does not mandate the protocol used by the client (as far as I know) so provided the plugin is loaded for the protocol (see plugins page in the CVSNT control panel server admin tool) it should work. Pserver apparently only encrypts passwords but if you are running on a secure internal development network behind a firewall this should not be an issue, and should also improve performance as the protocol is not having to encrypt everything.

No Comments »