Fixed creating of intermediary directories in upcoming release.

after update to version 2.4-SNAPSHOT (private-05/03/2012 01:35-jenkins)
I still got the error:
cvs checkout -P -D 08 May 2012 14:31:48 +0800 -d lib/flac-1.2.1 lib/flac-1.2.1
cvs [checkout aborted]: could not change directory to requested checkout directory `lib': No such file or directory

With the 2.4-SNAPSHOT, I find a need to use a back-slash for the "Local Name", then it works. For example:

Remote Name: lib/something
Local Name: lib\something

It properly puts the checkout to workspace/project/lib/something. If I set "Local Name" to be lib/something, I get that same error 'No such file or directory'... My build server is Windows 7 with the cygpath plug-in if that matters. Anyway, it is working for me this way. Thanks Michael.

James: could you give some details as to what environment you're running in - is it Windows?

Yes, it is Windows 7 64-bit with Jenkins 1.464 installed as a service.

I've experienced the same issue and traced it down to a cvsnt inconvenience.
I'll try to explain my findings.
The -d argument gets passed to the server. The server process creates a local copy in a tmp dir for the checkout with that argument as name. It does not create the required subdirectories and thats why the checkout will fail. I assume your cvsnt/cvs server is running in a unix environment, because it works with backslashes for you. I've discovered the same workaround. It's working because backslashes are valid in unix filenames/directories, and the first level directory is created in the tmpdir.
I suggest not to pass the -d argument to the server, when doing 'partial checkouts' with subdirs.
I'd rather suggest to implement a client-side redirection of the files/directories.

Valentin: based in your comment, do you think changing the CVS command to contain backward slashes for the '-d' argument work in both Windows and Linux (i.e. cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib\flac-1.2.1 lib/flac-1.2.1)? My test machine is Windows Client -> Windows Server so I can't replicate the defect properly.

I reckon that changing to use client side redirection would cause CVS not to create CVS control files in the expected location so I'd have to fiddle about a bit, but may be an option if the backslashes 'quick fix' I've suggested doesn't work.

Michael: I think the backslash trick works on windows client-side only, independend from the cvs-server platform. I haven't tried cvs on linux client yet. I don't recommend to change the CVS command to contain backslashes. I think you should ommit the -d option when the 'CVS Module' contains slashes. The chekckout-as feature does not work with partial checkouts. I'd prefer a working 'partial checkout' feature over the 'checkout-as' feature, since it worked out of the box with versions < 2.0 of the CVS Plugin.

I've just tried the -d argument on linux client with backslashes, it's not what you want. It creates the directory with the backslash in it.

Code changed in jenkins
User: mc1arke
Path:
src/main/java/hudson/scm/CVSSCM.java
http://jenkins-ci.org/commit/cvs-plugin/70a90ec03ace11a703747e2317a6a3ad6a7e4112
Log:
[FIXED JENKINS-13264] Allow checkout of submodules