If you're using CVS on Windows (e.g. WinCVS or TortoiseCVS) and you get a message like:

cvs [update aborted]: cannot rename file _new_myhelpfile.chm to myhelpfile.chm: Permission denied

in WinCVS, or:

Unable to rename file _new_myhelpfile.chm to myhelpfile.chm for 1 second, still trying...
Unable to rename file _new_myhelpfile.chm to myhelpfile.chm for 2 seconds, still trying...

in TortoiseCVS, it means that some other program on your computer is using the file in question and preventing CVS from overwriting it.

In the example above, myhelpfile.chm is an HTML Help file, so the chances are that the file is currently open in a Help viewer (or perhaps being used by RoboHelp or HTML Help Workshop). Exit whatever program has a lock on the file and you will be able to update it successfully.

To set up WinCVS to work over SSH:

Get the software

If you've got a 1.x version of WinCVS, uninstall it now and restart your computer.

Download & install the latest stable version of WinCVS from:
www.wincvs.org

At the end of the install, the installer will tell you if it can't find Python. If you don't have python, download & install the latest stable version from:
www.python.org/download

The following instructions assume you already have PuTTY and you already use it for SSH connections to the remote network (which I'll assume is your office).

If you don't have PuTTY, you can download it from:
www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Port forward the CVS port

Set up a new tunnel in PuTTY (i.e. forward a local port to a port on a remote computer).

By default the CVS server listens for connections on port 2401 and this is the port to which WinCVS talks. You therefore have to forward port 2401 on the local machine (127.0.0.1) to port 2401 on the remote CVS server (e.g. cvs.yourcompany.co.uk).

To do this in PuTTY:

1. Load the session that you use to connect to the remote network (e.g. you office network).

   I'm assuming you already SSH to this network so you have already set up and saved the settings for a login session to this network in PuTTY.

2. In the left pane, go to Connection > SSH > Tunnels.
3. Enter 2401 in the Source Port field.
4. Enter either hostname:2407 or IPaddress:2407 in the Destination field.
5. For example: cvs.yourcompany.co.uk:2407
6. In the left pane, click Session.
7. Click Save.

The next time you use this saved session to login to the remote network, the tunnel will be established, so that anything sent to port 2407 on your local computer will be forwarded through to port 2407 on the CVS server on the remote network.

Setting up WinCVS

If you're upgrading from an old version of WinCVS you will notice that the CVSROOT is no longer specified in the Admin > Preferences dialog box. It's now in the Admin > Login dialog box.

:pserver:[username]@[servername]:/[path]

For example:

:pserver:john@cvs:/yourcompany/repository

WinCVS sends the above login request to the server as the command:

cvs -d :pserver:john@cvs:/yourcompany/repository login

This is what you would enter if you were using CVS from a command line.

If you try to log in now, the login will fail because your computer will not be able to find the host you are trying to connect to. In the above example, the server name is cvs. Your computer needs some way of resolving this host name to an IP address. You do this using the Windows hosts file.

Use a text editor to edit the hosts file. This usually resides in the directory:

[Windows installation directory]\system32\drivers\etc
e.g.
C:\WINDOWS\system32\drivers\etc

At the end of this file add:

127.0.0.1  [server name]          # Your comment

For example:

127.0.0.1  cvs                    # Map this host name to the local host
127.0.0.1  cvs.yourcompany.co.uk  # Map this domain to the local host

Save the file.

Now, when you try to access a server named cvs or a domain named cvs.yourcompany.co.uk, your computer knows to use the IP address 127.0.0.1, which is the local computer. The name "cvs", in this example, is identical to "localhost" – both are aliases for the IP address 127.0.0.1.

The result of this is that, while you are logged on to the remote network, local port 2407 is forwarded to the remote CVS server, so connections to port 2407 on cvs (in the example above) are directed to the remote server (which, in our example, also happens to be called cvs). Using the hosts file in this way allows you to use the same server name (e.g. "cvs") as you do when you are working on a machine in your office that is part of your office network domain.

Logging in

Usually you can simply log in to the CVS server using your network username/password. However, the server may be set up to use localhost authentication, using its own password file. The server may also be set up to use both types of authentication, trying to authenticate locally first and then falling back on network authentication.

If the server uses local authentication, you must ask the administrator to add your password to the password file. Usually this is done using an encryption program to generate an encrypted password which you then give to the administrator to put in the password file.

A typical scenario would be to use a mkcvspwd program on a networked server to which you *do* have access to:

1. Run the encryption program (using the command mkcvspwd – if that's what it's called and it's in a sensible place like /usr/local/bin, or [path]/[program] if not)
2. Type in the new password twice.
3. Copy the encrypted version that the program supplies.
4. Email this to the administrator and ask him/her to put it in the password file for CVS.

Once you've set up a server-specific password, you obviously must remember it or you won't be able to use CVS. If you forget your password, repeat the above process.

Once you've logged in you can do all the usual CVS stuff, just like you were working on a PC at the remote location: e.g. check out a module, work on a file, update it, commit it.
Read the rest of this entry »

Lots of thoughts about Adobe's takeover of Macromedia here:

http://blogs.pcworld.com/techlog/archives/000614.html

One correspondent makes the observation that, with such a huge product line now, Adobe will not want to spend money developing all of these lines. RoboHelp must surely fall into this bracket. As a product that has not been actively developed over the past few months, and a product that needs a thorough overhaul to be able to produce XML-based Help - e.g. using MAML (Microsoft [User] Assistance Markup Language) - Adobe either need to spend a lot of money on RoboHelp, or its future is bleak.

Adobe may, of course, adopt the same approach to RoboHelp that they have to FrameMaker. Like FrameMaker, RoboHelp is a niche product with a small user-base whose members do not have much choice in the way of alternative products. Adobe have kept FrameMaker on life-support for the past few years and they may choose to do the same with RoboHelp. This provides them with a small but steady income for next to no outlay and, because of the product is so well established in the market, it stifles competition quite effectively, which leaves Adobe's options open should they ever choose to create a replacement product.

The big news this morning is that Adobe are buying Macromedia. See this morning's press release at:

www.macromedia.com/macromedia/proom/pr/2005/adobe_macromedia.html

It's going to be very interesting to see what will happen to RoboHelp and Dreamweaver now.

See also my entry on the demise of RoboHelp.

Macromedia chose not to attend the recent WritersUA Conference in Las Vegas. After the lay-off of the RoboHelp development team last year, this non-attendance confirmed the belief of many that Macromedia has decided not to develop RoboHelp any further. It will still be sold and supported - just not actively developed. This puts it in the same becalmed boat as FrameMaker - still afloat, just not going anywhere.

At the time of writing there's an interesting discussion about this on the Macromedia General Discussion forum:
www.macromedia.com/cfusion/webforums/forum/messageview.cfm?catid=447&threadid=979594&forumid=65

At first it seems odd that Macromedia should spend $65M on aquiring eHelp and then decide not to continue development on eHelp's flagship product. However, probably shouldn't be too surprising. The future of technical documentation is XML-based and many technical authors are looking for tools that will support the creation and maintenance of MAML-based documents. Whatever the eventual successor to FrameMaker and RoboHelp turns out to be (perhaps something from Madcap, perhaps something from ArborText, perhaps something Macromedia have up their sleeves) it will need to be built around MAML, and almost certainly (though perhaps as a by-product rather than a main aim) make DocBook authoring much simpler than it is right now.