Move some ClearCase labels with TeamCity VCS plugin

Hello,

Making some tests with VCS labeling, I have noticed something strange...

No problem labeling with TeamCity when using new labeling patterns or incremented labeling patterns.

But, when using a fixed pattern, items that have changed (so that are in a new version) sinced last Build (so since last labeling) are not labeled on their new version.

As an example, there were an existing version before changes:
E:\CCase\xxx_tcdev_view\xxx\Sandbox\AnotherConsoleApplication\AnotherConsoleApplication\Program.cs@@\main\9 (ACA-FastIntegrationBuild)

Changes makes a new version: Program.cs@@\main\10

The command is made on the next version:
cleartool mklabel -version \main\10 ACA-FastIntegrationBuild E:\CCase\xxx_tcdev_view\xxx\Sandbox\AnotherConsoleApplication@@\main\10\AnotherConsoleApplication\main\5\Program.cs\main\10

What is strange is that if I use the cleartool command myself in a command prompt I get an error message whereas I can't see such error message in log files...
cleartool: Error: Version label of type "ACA-FastIntegrationBuild" already on element.

cleartool: Error: Trouble applying label to ...

A solution could be to use the "-replace" flag.

I'm using TeamCity 4.0.2 and ClearCase 7.0.0.1 on Windows.

Regards,

Olivier.

9 comments
Comment actions Permalink

Hello,

Thank you for the information, I added "-replace" option to both commands "mklbtype" and "mklabel".

I can provide you a patched "clearcase.jar" file if you want.

0
Comment actions Permalink
I can provide you a patched "clearcase.jar" file if you want.

Yes. I'd like to.

Olivier.

0
Comment actions Permalink

Please replace your "<TeamCity Home>\webapps\ROOT\WEB-INF\plugins\clearcase\server\clearcase.jar" file with the attached one.



Attachment(s):
clearcase.jar
0
Comment actions Permalink

Hi Maxim,

I've tested the jar you provided on my TeamCity 4.0.2 instance.

It solves the ClearCase existing label move but now fails the labeling with an new pattern (nominal test)...

I think the problem is that the "-replace" flag shouldn't be always used, but only when the label already exists (so it has to be moved), when applying (not creating label).

Regards,

Olivier.

0
Comment actions Permalink

After looking more in ClearCase plugin source code from SVN and ClearCase documentation, I'm just adding some notes to the previous message to help correction.

  • About creating the label: this task should only be done if no label already exist.
    And I thing that the "-replace" flag is unecessary.

mklbtype (Creates or updates a label type object)
-replace (Replaces the existing definition of type-name with a new one)

  • About applying the label: the flag "-replace" should be used only if the label has already been used (so let's say if it has already been created before that Build)

mklabel (Attaches version labels to versions of elements)

I thing a solution for checking if a label already exists is to use the following cleartool command:
cleartool> lstype -kind lbtype -short
And this command could be called before the previous two actions.

Best regards,

Olivier.

0
Comment actions Permalink

I fixed this bug, now "-replace" option of "mklbtype" command is added only if label exists. In command "mklabel" it is always added because this command doesn't raise an error in any case.

I created an issue in our tracker: http://jetbrains.net/tracker/issue/TW-8200, you can find patch for TC 4.0.2 there.

0
Comment actions Permalink

Hi,

I've just tested the patch for 4.0.2. There are some problems with:
- new labels (label creation)
- moving existing labels

I've put some traces on the tracker:
http://jetbrains.net/tracker/issue/TW-8200

It may be re-open...

Regards,

Olivier.

0
Comment actions Permalink

Hello,

Seems I fixed it, see the tracker, please.

0
Comment actions Permalink

Sorry, I did post on the forum and on the tracker.

Now, I've just tested the patch you delivered this afternoon and it seems it solves all problems.

Thanks for your help,

Olivier.

0

Please sign in to leave a comment.