Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
UpdateTask - Stuck in Resolve Conflict
B80116
Hello everyone,
I am trying to incorporate the "updatetask" into one of our workflows; this is my first experience with using the updatetask. To try to isolate the problem, I have written a simple workflow (see attached) consisting of four tasks:
User Task 1
Update Task 1
User Task 2
End
User Task 1 and User Task 2 have different areavpaths (workareas).
As we begin, a file exists and is the same in both workareas. The file has not yet been submitted to Staging.
I make some changes to the file in Workarea 1.
The workflow is instantiated using File|New Job.
In User Task 1, I add the existing, modified file to the workflow and select "Done".
Update Task 1 is activated. Update Task 1 is supposed to update Workarea 2 with the attached file from Workarea 1. Because the Workarea 1 file is different from the Workarea 2 file, Update Task 1 informs me that I need to "Resolve Conflict".
So far, so good.
I select "Resolve Conflict". The Task Conflict screen informs me "Conflicts found during update." So I select the file name and click Merge. The Merge window informs me in the lower left corner "1 difference found". So I click "Next Difference" and "Accept New Change".
A pop-up informs me "End of document. No more unresolved differences." I close the pop-up and select File|Save and Exit. The Merge window closes. I then click "Continue Update" in the Task Conflict screen, and I am back in my To-Do list. But here is the problem. Update Task 1 still only offers me the "Resolve Conflict" option. I cannot move forward to User Task 2.
If I go to Workarea 2 and open the file, I can see that it has been successfully updated.
If I try to resolve the conflict again, I am still told that there were "Conflicts found during update" and "1 difference found". If I go through the Merge process again, I still am stuck in the "Resolve Conflict" stage of Update Task 1.
Can anyone see what I am doing wrong?
Thanks for any insight you can provide. I've seen a few other threads which mention getting stuck in this kind of updatetask loop, but they don't offer any solution.
By the way, this is TeamSite 5.5.2 running on Windows 2000 Server.
Find more posts tagged with
Comments
Migrateduser
I have had a simliar problem in the past - not the same scenario but the same result. We have updatetasks in one of our main workflows. Every so often, usually when someone pushes the entire site, the updatetask will get stuck in a never fixable Resolve Conflict state. The only way to get past it is to kill the job and perform all the rest of the steps in the job manually. I think I even posted about this problem once upon a time in DevNet but got no useful responses. Whenever this happens there is no way to get past the Resolve Conflict - it is one of the most frustrating things about TeamSite - that annoying Resolve Conflict UI. Anyway, never did figure out how to fix it. We're using TS 5.5.2 on Solaris.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
B80116
Wow, that's discouraging.
So far, for this simple little workflow, it's happening ALL the time, EVERY time, which makes me think maybe I'm doing something wrong.
Anyone else have any ideas?
nipper
2 people changed something. Thus someone's changes are gonna get stepped on. First and formost check WHY you are getting the error.
Do a compare before you submit.
I see this sometimes. Reasons could be someone is not doing a get latest (or the WF is not)
In Smitty's environment, it gets worse since they do not lock when using FTP.
Locking is a good thing, so is get latest.
When you do have a conflict in the WF, you have 2 choices you can cancel and merge, if there are truly 2 disparate changes & you want to keep both. Or you can continue the submit (and click the overwrite). WARNING: This is a big gun, don't shoot yourself.
Overwrite and not using Get Latest is a recipe for disaster.
HTH, Andy
Adam Stoller
Since you apparently have a nice small reproducible case - I suggest you contact Support and see if they can replicate the problem in-house. That's the best way to get things like this resolved.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
B80116
Ok, thanks ghoti. I have opened a ticket and support is now looking into it. If/when we get this figured out, I'll post back here. Thanks everyone who responded.
B80116
This is interesting. And discouraging. I just found this Knowledgebase article:
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=50519
It describes exactly what I am experiencing, except I'm using TS 5.5.2, and the article is about TS 6.0.
Basically, the article is recommending that instead of doing an update between workareas, you should do a submit to staging from workarea1, and then update from staging to workarea2. The article calls this a "best practice".
That would be great, except that our own "best practice" is to not submit anything to staging unless it has been approved for release to production by our QA group. We QA code, and if approved, we submit to staging, publish an edition, and deploy that edition. We don't want to use the staging area as a "temp file" location for untested code.
Sigh....so basically Interwoven is saying don't use the workflow updatetask to update files in one workarea with the files from another workarea, even though that's what the updatetask is for. And then they classify the workaround as a "best practice"???
Adam Stoller
It's a tricky situation, merging changes in workareas without using staging. If you just did an overwrite for the files in question I think the problem goes away - yes? Is that an option for you?
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
B80116
Yes, if we do an overwrite, the updatetask completes. That problem goes away, but if you are the developer whose code just got overwritten without being given the opportunity to merge, there is a new problem.
So that's not an option for us with our current code management strategy (multiple developers, each with his/her own workarea).
I guess if Interwoven officially tells us that we can't use the updatetask to do updates between workareas, then we'll have to redesign our code management strategy (maybe just one workarea, thereby losing the ability of our developers to develop concurrently.)
I don't understand why you say merging changes in workareas without using staging is a tricky situation. It seems like something very common and straightforward that customers would want/need to be able to do.
I also don't understand why Interwoven thinks it's a "best practice" to use the staging area as some sort of "swap variable" in order to work around the updatetask not working (unless you do an overwrite). Staging is going to have code in it that hasn't been tested; editions could be published and deployed with untested code in it.
Maybe we are just wrong in planning to use the Staging area as a repository for fully-tested code before moving it out to production? But that's what a Staging area is supposed to be, right?
Migrateduser
I have to agree with you. We have virtually the same setup. We have an integration workarea and a qa workarea and our STAGING area only gets updated when we are ready to move files to production (after QA). When any of our users pushes an entire site (the site already exists, there are just massive changes), the updatetask that copies the files from the integration workarea to the QA workarea gets stuck in a Resolve Conflict black hole. No matter what I do, even manually copying the files from integration to QA, the Resolve conflict never goes away. This is a full on bug.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
james1
Have you considered using a sub-branch to allow developers to check in to staging without polluting the "real" staging area (on the parent branch)? That may or may not be an option for you.
Also, if you just want to merge the conflicting files, doesn't the UI provide a way to do that? TS6.0 definitely does. Or are you having problems finishing the task, regardless of merging?
-- James
--
James H Koh
Interwoven Engineering
B80116
We are able to go through the Merge process, but even after we complete that, the updatetask is still only giving us the option to "Resolve Conflict". It (or TeamSite) still thinks a conflict exists between the file in workarea1 and workarea2.
Can you expand any on the sub-branch idea?
And aren't you supposed to be in a WebCast about now?
I've re-read your message, and I see now what you are saying about the sub-branch idea. Let me think about that...
Edited by B80116 on 02/25/04 09:42 AM (server time).
Adam Stoller
A sub-branch for development is a clean way of doing things.
The problem with the modifications in two workareas
without
using a staging area is that the merge is essentially a 3-way merge whose objective is to create a new direct descendent:
This File
,
That File
,
Common Ancestor
.
The merge is a result of comparing the differences between ((
This File
<=>
Common Ancestor
) <=> (
That File
<=>
Common Ancestor
)) =>
New Descendent
.
In the "normal" conflict resolution scenario -
This File
will be something like version
3+
,
That File
will be version
4
and
Common Ancestor
will be version
3
:
((
3+
<=>
3
) <=> (
4
<=>
3
)) =>
4+
-- note that '
4
' is essentially a non-moving target in this case, and the result of performing this merge is to generate version
4+
- which means that
This File
(
4+
) is now a direct descendent of
That File
(
4
).
With the two workarea comparison you might have:
((
3a+
<=>
3
) <=> (
3+
<=>
3
)) =>
3c+
-- both
3a+
and
3+
are "moving" or at least "movable" targets. The result of this merge is essentially
3c+
and
This File
is still not a direct descendent of
That File
- and neither
This File
nor
That File
represents the
Common Ancestor
, so both
This File
and
That File
are still out of sync after the merge has been completed. One second after the merge has been completed, there's no way to determine whether
3a+
or
3+
have changed with respect to each other - the only way is to compare them against their
Common Ancestor
and ... they both appear to be different and thus they both need to be merged again...
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
Oh my ****. I'm just gonna take your word for it that using 2 workareas is a bad idea. So what's the structure for the sub-branch model when we need a development area, a QA area and a common STAGING area such that files can be modified in the development area, sent to QA for testing, then either rolled back to be modified again (in which case the QA area is refreshed to match STAGING) or pushed through to STAGING and ultimately deployed to production?
I'd love to see the branching/workarea structure and the sequence of events of moving the files around. This could actually be something useful for us.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Adam Stoller
If I find time, and someone else hasn't already produced the diagram for you ... (it's not really that tricky - it actually looks like pre-TS4.0 workflow diagrams or what I liked to call salmon workflows ;-))
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
Does QA ever need to make changes to files, or do they just consume the latest "blessed" set of files? If QA only consumes files, then they could just use published editions. When a branch is "ready to send to QA", you would publish an edition. Then QA could either use that edition directly, or use their own workarea based upon that edition. It should then be fairly easy for them to switch back to an earlier edition if desired.
Brinko Kobrin
Interwoven Staff Engineer
Duplex_Unit.png
Migrateduser
QA will never make changes to the files. I hesitate to say that using Editions is a good idea because Editions are typically what are used to rollback production should that ever need to happen. We publish an edition every time we deploy to production. I suppose we could use naming conventions to name Editions as QA or Prod, but I would like to see what the sub-branch solution looks like before committing to the Edition idea. It is good to have options, though, so thanks Brinko.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
james1
I'll try to describe it without pictures.
You have your "main" branch. This is, in your current world, the only branch you have. You now also have your "sub-branch", a child of the main branch.
Your main branch has one and only one workarea, let's call it "QA".
Your sub-branch has one workarea for each developer (or whatever policy you choose). The developers work all day, and they submit as often as they want (or whatever policy they choose). Point is, they get to submit more often than they do today. There should no longer be workarea-to-workarea updates, only submits and get latests.
Only in a while, the sub-branch publishes an edition of something it thinks is good. That edition gets updated to the main branch's QA workarea. QA takes a look. If QA approves it, the submit the entire QA workarea, publish an edition, and deploy that edition whenever you feel it is appropriate (now, midnight, whatever).
This allows your developers to get versions of their work (by submitting to the sub-branch's staging area early and often), while "releasing" only the choicest of editions to QA for a QA cycle. QA gets to pull the final trigger (submit-and-deploy, on the main branch).
Hope that helps.
-- James
--
James H Koh
Interwoven Engineering
B80116
Interwoven Technical Support has acknowledged that the failure of the updatetask to let you out of the "Resolve Conflict" stage after you have merged changes (ie, resolved all differences) "seems to be" a bug. They have assigned it bug id 51884.
They also acknowledged that what I was trying to do with the updatetask was a very basic application of the updatetask, and that I wasn't trying to do anything out-of-the-ordinary.
"Yes what you are trying to do is basic and it should have worked, but unfortunately it seems to be a bug which we did not catch."
james1
Within Interwoven Engineering, we use TeamSite as a source code version control system. Our standard workflow utilizes an updatetask, and we do have to merge once in a while. I'm not sure why it works for us and not for you. I suppose someone will investigate the bug report and find out.
-- James
--
James H Koh
Interwoven Engineering
inwinchester
Has anyone had any resolution on the above bug (51884?) ...
I've searched for patches for Bug ID 51884 and nothing appears.
This seems like a major bug, but it hasn't been fixed in 2 years+ ????
Anyone come up with a decent workaround to this?
