When configuring base clearcase for snapshot view, there is a cc.viewpath option which allows to define directory name under which the view will be created in workspace. So if I configure the build with defaults for view tag (${USER_NAME}${NODE_NAME}${JOB_NAME}_hudson) and view path (view), I will end up with view named raspy_master_test_hudson created as D:\profiles\raspy\NetBeansProjects\hudson-clearcase-plugin.git\work\jobs\test\workspace\view. So we have:

PS D:\profiles\raspy\NetBeansProjects\hudson-clearcase-plugin.git\work\jobs\test\workspace\view> cleartool pwv -s
raspy_master_test_hudson
PS D:\profiles\raspy\NetBeansProjects\hudson-clearcase-plugin.git\work\jobs\test\workspace\view> cleartool pwv -root
D:\profiles\raspy\NetBeansProjects\hudson-clearcase-plugin.git\work\jobs\test\workspace\view

Now the following problem arises:

When polling for changes, changelog does not have its viewroot stripped. This is directly caused by the following code in ClearCaseSCM.createHistoryAction:

String viewName = generateNormalizedViewName(variableResolver);
String pwv = ct.pwv(viewName);

This tries to enter D:\profiles\raspy\NetBeansProjects\hudson-clearcase-plugin.git\work\jobs\test\workspace\raspy_master_test_hudson directory (which does not exist), so it does not set extendedViewPath and thus it doesn't get stripped later at changelog.

I tried to fix it by replacing call to generateNormalizedViewName(variableResolver) with getViewPath(variableResolver) and it solved the changelog problem (as the viewpath checked is now correct), but it caused ClearCaseSCMTest.assertExtendedViewPathUsesNormalizedViewName to fail. This in turn makes me wonder that such behavior was by design. To be even more confused, I find in help (localdir.html) those two contrary (I believe) statements:

1. If the view path is left empty, the view tag will be used as view path.
2. The view path relative to the workspace is available as an environment variable named CLEARCASE_VIEWNAME.

Well, apparently CLEARCASE_VIEWNAME is a view tag, which may or may not be included in CLEARCASE_VIEWPATH. However, in the help statement above as well as in code (at least the unit test I mentioned) there is an assumption that this is always the case (that view path ends in view tag).

I would like somebody involved in plugin's development (vlatombe? to look into this and tell me whether current implementation is wrong, so I could fix it as stated above, or is there something more that I'm missing?