update task not working

TS 552, Solaris 8

Hi,

I'm sure this is something I'm doing wrong but I can't see it. I have a very simple workflow with one job to update a file from a release area to a user area. I know that the file is in conflict and so I should get a merge job. What I actually get is the task is created and disappears. I'm seeing nothing in the logs (iwtrace.log or iwjoberrors.log). All the workareas/files exist. Here is the workflow:

<workflow name="Merge Task" owner="admin" creator = "admin">
<updatetask lock = "f"
name = "Conflicts in MR0007_test"
owner = "john"
delete = "t"
start = "t"
description = "MR0007_test has files in conflict">
<areavpath v="/default/main/AA/MR/MR0007_test/WORKAREA/MR0007_test"/>
<successorset description = "OK">
<succ v="EndTask"/>
</successorset>
<srcareavpath v="/default/main/AA/Release/EDITION/20030804_Baseline_009"/>
<files>
<file path="cdc240501.html" comment="File in conflict with release 20030804_Baseline_009"/>
</files>
</updatetask>
<endtask name = "EndTask" />
</workflow>

The workflow is generated by an external task but I have been running it manually using:

iwjobc -i /tmp/MR0007_test.wft

Can anyone see an error with this. Any help would be appreciated as I have gone mad today looking at this. The 5.5.2 SP3 manual does provide better info but I still can't see what is wrong.

Regards

John

Find more posts tagged with

Comments

mgal

Do you see any messages in iwevents log? What happens if you try to update a file which is not present in the destination workarea? Does the file get updated from the source?

johnjamesmarsh

Ok, in the events log I get:

[Tue Aug 5 08:24:09 2003] marshj master TaskAddFile Merge Task 0x421 Conflicts in MR0007_test 0x422 cdc240501.html
[Tue Aug 5 08:24:09 2003] marshj master WorkflowActivate workflow Merge Task 0x421
[Tue Aug 5 08:24:09 2003] marshj master TaskGoActive Merge Task 0x421 Conflicts in MR0007_test 0x422
[Tue Aug 5 08:24:09 2003] marshj master TaskActivate Merge Task 0x421 EndTask 0x423 Conflicts in MR0007_test 0x422
[Tue Aug 5 08:24:09 2003] marshj master TaskInactivate Merge Task 0x421 Conflicts in MR0007_test 0x422
[Tue Aug 5 08:24:09 2003] marshj master TaskGoActive Merge Task 0x421 EndTask 0x423
[Tue Aug 5 08:24:09 2003] marshj master WorkflowInactivate workflow Merge Task 0x421

But there is no conflict task produced ("Conflicts in MR0007_test" is the name of my task). I tried running the task with overwritemod="t" and that overwrote the file (hopefully showing I am in the right area). I tried, as you suggested, running the task on an area where the file did not exist and that added the file (as expected). I tried to reason with the system but it nonchalantly ignored me.

I can add a CGI task that will give me a form to display to the user the files in conflict just I wanted to use the update task functionality :-( If you have any other suggestions/ideas I would be more than happy to hear them.

Adam Stoller

I'm not 100% positive, but I believe you will only get a conflict if the srcareavpath points to STAGING - you're setting it to an EDITION. Another slant on this would be that if the version of the file in the workarea is in sync with the version in STAGING that regardless of which version you're comparing it to, it will not be in conflict. If, however, the version in the workarea is *not* in sync with the version in staging, you might get the conflict to appear when comparing it against an edition.

I have not tried this out, I'm merely speculating at this point as to why you might be seeing the behavior you're seeing.

--fish
(Interwoven Senior Technical Consultant)

johnjamesmarsh

Thanks for the input. I tried changing the srcareapath to be the staging area and still did not get a conflict. I tried in the Release branch and in their own branch. I was hoping this was just a stupid typo I had made (as I am prone to them).

Have you ever seen a conflict produced by an update task? This is the first time I have tried to use an updatetask as I usually do updates via the command line. Where I found a conflict I wanted to show it to the user for them to deal with (hence the update task). Alternatively any other ideas on how to flag to the user that they have conflicts in their workarea and they need to deal with them.

Adam Stoller

Doing some cursory testing on a TeamSite 552 SP2b Solaris system, I find that running
iwupdate /.../STAGING /.../WORKAREA/waname

can produce a single error message of "ERROR:02016: Conflicts prevent operation for /.../STAGING", and I can get the exact same message when comparing an edition to the workarea.

However, in another branch, where I ran the same command first from STAGING, and received a few updates but no conflicts, I was unable to get any conflict message when then comparing the workarea against any of the older editions. Thus, I believe it is safe to say that, at least currently, if the files are not in conflict with the associated staging area, they will not be indicated as in conflict with any other area

If you are using a single-workarea-per-branch setup (which I see at a number of different customer sites), you will not be able to introduce a conflict with staging. Conflicts only arise from having multiple workareas, where the same version of the same file is edited in two [or more] workareas, and one modified version has been submitted. At that point, all other modified copies of the original version will be in conflict with staging.

If you want to determine whether files differ in one area from another, regardless of how many workareas you may have on that branch - you can use the output from iwcmp. If you find an entry with '+' in both of the first two columns, that file is, I believe, in conflict. If you see a '+' in only one of the columns, that version of the file associated with the particular column, is modified with respect to the other area. If you see different character-keys in the two columns, that also represents a modification (and might represent a conflict - not sure)

If you only want to determine the files that have been modified in a workarea with respect to its associated staging area, iwlistmod may be a more efficient tool to use.

Hope that helps.

--fish
(Interwoven Senior Technical Consultant)

johnjamesmarsh

Thanks for that. I think you've hit the nail on the head. I am indeed working in a branch with only one workarea. My users are getting an e-mail already to tell them of conflicts so they will have to accept that if they ignore the e-mail then they will have conflicts when they submit their files.

Thanks for answering my question. It was starting to drive me a little mad.