nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CSSDK CSWorkarea update() method

Adam Stoller

Environment[indent]TS 672 SP2 + P1 on W2K3
CSURLExternalTask class[/indent]Issue[indent]I have some code to essentially perform an iwupdate from the staging area of one branch to a given workarea on a sub-branch.

    private void updateReleaseBranch() throws Exception {
        boolean problems = false;
        CSArea srcArea = getSrcArea();
        CSWorkarea tgtArea = getTgtArea();

        CSAreaRelativePath[] flist = task.getFiles();
        CSUpdateResult result = tgtArea.update(flist, srcArea, 
                                               CSWorkarea.OVERWRITE_ALL);
        CSFileCmpResult[] status = result.getResultOfUpdate();

        int max = flist.length;
        for (int i = 0; i < max; i++) {
            if ((status.getPrimaryStatusCode() != CSFileCmpResult.SUCCESS)
                    && (status.getSecondaryStatusCode() != CSFileCmpResult.SAME)) {
                problems = true;
                //...
            }
        }
        if (problems) {
            //...
        }
    }

My problem is with the highlighted portion of the code - when attempting to repeat the update process for a given file (testing purposes right now). Through some debugging statements I've determined that:

.isSame())){ //... }but that didn't seem to do any better.

Find more posts tagged with

Comments

Migrateduser

I'm not sure if I'm following what you're exactly trying to accomplish but couldn't you add the following to your if statement?

[PHP]
&& (status.getStatusMessage!=null && !status.getStatusMessage.equals("File or directory is the same as the other version"))
[/PHP]

Migrateduser

I had to deal with these status codes for trying to debug a significant issue regarding submittig to STAGING and the primary status code I saw whenever the files were the same, and therefore not submitted, was 27. That seemed to be pretty consistent. So unless I'm not understanding what you're trying to accomplish (which is likely), why not just check to see if the primary status code is 27 and be done with it?

Adam Stoller

I'm not sure if I'm following what you're exactly trying to accomplish but couldn't you add the following to your if statement?

[PHP]
&& (status.getStatusMessage!=null && !status.getStatusMessage.equals("File or directory is the same as the other version"))
[/PHP]

Well - if I wanted to write some real shoddy code that doesn't account for string messages possibly getting changed in future releases - yes - I could do that - but I'd like to do this "right"

Adam Stoller

I had to deal with these status codes for trying to debug a significant issue regarding submittig to STAGING and the primary status code I saw whenever the files were the same, and therefore not submitted, was 27. That seemed to be pretty consistent. So unless I'm not understanding what you're trying to accomplish (which is likely), why not just check to see if the primary status code is 27 and be done with it?

I suppose I could, and I might, but that falls into much the same category as taalgaard's suggestion - I should be able to use a constant or method to filter out such non-important "errors" so that the code should continue to work even if the value of the constant or implementation of the method changes in a future release.

I may end up opening a case with Support for this (I already got them to acknowledge that the timestamp associated with comments as part of a workflow event is wrong)

ISCBorisB

I suppose I could, and I might, but that falls into much the same category as taalgaard's suggestion - I should be able to use a constant or method to filter out such non-important "errors" so that the code should continue to work even if the value of the constant or implementation of the method changes in a future release.

I may end up opening a case with Support for this (I already got them to acknowledge that the timestamp associated with comments as part of a workflow event is wrong)

To second Smitty somewhat...
2401 is actually an Error code that iwsubmit (not update!) returns when you try to submit non-modified File.

Since it is hard to believe in a coincidence in this case - perhaps objects of CSFileCmpResult type retain
(individually) actual Action state. Your update Operation did not apply to non-modified Files so they kept
the state of latest operation that did.

I'm speculating here but if that's the case, you can not use the class (not secondary Status,
anyway) to validate the latest operation, it's a residue of many prior operations

Migrateduser

I suppose I could, and I might, but that falls into much the same category as taalgaard's suggestion - I should be able to use a constant or method to filter out such non-important "errors" so that the code should continue to work even if the value of the constant or implementation of the method changes in a future release.

I may end up opening a case with Support for this (I already got them to acknowledge that the timestamp associated with comments as part of a workflow event is wrong)

I was not excited that the status codes are not easy to work with, either. In fact, I had written a support case just to complain about the way the status codes are documented, meaning NOT documented. I am perplexed and disappointed that your second approach (using the isSame() method) doesn't work the way you expected. I would definitely bring this up with support as that seems like it SHOULD work. And if it doesn't work, what exactly does it do?

Migrateduser

The status codes are documented. You just have to look in the correct place.

Look in the Command Line Tools documentation. You'll see the codes documented in the Appendix under Error Codes.

Your code should check for the 2401 error code since it corresponds to the "File or directory is the same as the other
version" error. The other error, 27 indicates "File too large.", choose to do with it what you will.

There, now you don't have to write "shoddy code".

Adam Stoller

The status codes are documented. You just have to look in the correct place.

Look in the Command Line Tools documentation. You'll see the codes documented in the Appendix under Error Codes.

Your code should check for the 2401 error code since it corresponds to the "File or directory is the same as the other
version" error. The other error, 27 indicates "File too large.", choose to do with it what you will.

There, now you don't have to write "shoddy code".

It's still shoddy code if I have to hard-code the number in my code - or did you never learn about good code writing practices?

You're also assuming that the 27 I get back as the primary status code is the same as the 27 documented in the CLT manual - which I doubt, since the file gets updated just fine when it doesn't exist in the target area.

In either case, I've opened a case with Support to see what they have to say.

Migrateduser

I either picture you as Sheldon from Big Bang, or the comic book guy from the Simpsons. Either way, it makes me laugh.

Migrateduser

The status codes are documented. You just have to look in the correct place.

Look in the Command Line Tools documentation. You'll see the codes documented in the Appendix under Error Codes.

Your code should check for the 2401 error code since it corresponds to the "File or directory is the same as the other
version" error. The other error, 27 indicates "File too large.", choose to do with it what you will.

There, now you don't have to write "shoddy code".

And you are pompous beyond belief. If you think the CLT manual is up-to-date, you are also a dreamer. And no help whatsoever.

I prefer to look at the javadocs, which gives a fairly comprehensive list of constant values and codes. If you look at the javadocs, the only place a status code of 27 appears is under CSConflidtException, and 27 corresponds to EXCEPTION_ID. Very helpful, Interwoven. Thanks so much. Almost as helpful as taalgaard...

However, as ghoti has already pointed out, a primary status code of 27 corresponds to a status message of "File or directory is the same as the other version". "File too large" has no context in the function we are even talking about. So you are only confusing the matter, not helping.

Migrateduser

However, as ghoti has already pointed out, a primary status code of 27 corresponds to a status message of "File or directory is the same as the other version".

Are you sure you read the JavaDocs? Doesn't appear that you did.

Because it says that getStatusMessage is from the secondary status code. That would be 2401.

getStatusMessage
public java.lang.String getStatusMessage()Returns a localized message conveying the meaning of the secondary status code.
Returns:
the status message

Also, "file or directory is the same as the other version" is not contained within a single jar, so it must be coming from somewhere else.