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; } } }

Reason for File Conflicts in submit task

System

Hi All,

I want to know the scenarios in which, the submit task stucks giving the file conflict message.

Does the submit task stucks because of the value of 'override' attribute?

Does a locked file also cause file conflict message?

Thanks in advance.

Find more posts tagged with

Comments

ISCBorisB

Hi All,

I want to know the scenarios in which, the submit task stucks giving the file conflict message.

Does the submit task stucks because of the value of 'override' attribute?

Does a locked file also cause file conflict message?

Thanks in advance.

Migrateduser

The Resolve Conflict window is and has always been the worst UI ever built in the history of UI's. It is not intuitive and sometimes doesn't overrride when you tell it to. It is a horrible UI.

ISCBorisB

The Resolve Conflict window is and has always been the worst UI ever built in the history of UI's

Intelligence is limited and stupidity is infinite. Ever tried ClearCase?

cute_guy

The Resolve Conflict window is and has always been the worst UI ever built in the history of UI's. It is not intuitive and sometimes doesn't overrride when you tell it to. It is a horrible UI.

This happens when there are stale locks present in the workarea.
Folder containing the locked files would have been deleted which result in stale locks

Migrateduser

And yet it should still do the right thing and resolve itself if you tell it to continue with override. But it doesn't and you get no feedback whatsoever as to why. It just ends up with an endless loop - you can never get rid of the stupid conflicts and you are essentially stuck.

Adam Stoller

[QUOTE=ISCBorisB]

A file locked in a workarea other than the one being submitted will cause a conflict (of sorts).

Adam Stoller

The Resolve Conflict window is and has always been the worst UI ever built in the history of UI's. It is not intuitive and sometimes doesn't overrride when you tell it to. It is a horrible UI.

Worse than WFB ? ;-)

Migrateduser

Thanks to all for your replies. Those helped me to understand the problem.

In my case, I am getting the file conflicts due differences in versions.

My workarea file has a version 8+ while Staging file has a version 10.
I am wondering how this happened. We don't have multiple workareas in the branch. Can you share your opinions on this?

another thing I noticed about this file is, when I checked the versions of the file, all the previous versions were missing. I could only see version 10 and 9 in staging and only 8+ in workarea. What could be the reason of missing versions?

Thanks.

Adam Stoller

Thanks to all for your replies. Those helped me to understand the problem.

In my case, I am getting the file conflicts due differences in versions.

My workarea file has a version 8+ while Staging file has a version 10.
I am wondering how this happened. We don't have multiple workareas in the branch. Can you share your opinions on this?

another thing I noticed about this file is, when I checked the versions of the file, all the previous versions were missing. I could only see version 10 and 9 in staging and only 8+ in workarea. What could be the reason of missing versions?

Thanks.

When was the last time your backing store was iwfsck'd?
Are you sure you're using TS (what version?) on a supported OS (what OS/version?) with a properly supported JRE (what version?) via a supported browser (what vendor/version?)

Also - are you sure someone didn't create a second workarea, do some work and then remove the workarea? You might want to check the iwtrace and iwevents log files ...

Migrateduser

Worse than WFB ? ;-)

Ha! Good point. I'll clarify and say that because WFB was something you could choose to use, or not, it doesn't count. When you hit the Resolve Conflict window, you are screwed if you select "override" and it doesn't. Excellent point, though.

Migrateduser

When was the last time your backing store was iwfsck'd?

Can you tell me how do I check that?

Are you sure you're using TS (what version?)

I am using TS 6.5 SP3

supported OS (what OS/version?)

It is SunOS 5.8

The Teamsite application is installed on
with a properly supported JRE (what version?)

JVM 1.4

The Teamsite application is installed on
via a supported browser (what vendor/version?)

IE 6.0 sp2

Also - are you sure someone didn't create a second workarea, do some work and then remove the workarea?

Yes, I am sure there is no workarea in the same branch. However there is a workarea with same name in different branch but I guess it won't affect this workarea as it has its own Staging area. And if there were any copying from these two workareas, it would have been shown in file versions.

You might want to check the iwtrace and iwevents log files ...

I did not find any activity regarding this in iwtrace.

Thanks for the help.

Adam Stoller

When was the last time your backing store was iwfsck'd?
Can you tell me how do I check that?

If you're not the maintainer of the system - check with the maintainer.
If you are the maintainer of the system and you don't know - then chances are it hasn't been run - at least not since you were maintainer....

Read the TeamSite Administrator's Guide for more details - and check with Support if you have any questions about the output (NOTE: only use the -d and possibly -b flags --- do NOT use the -y flag)