submitting a deleted folder causes conflict

Whenever we submit a deleted folder in TeamSite 6.1, it causes a conflict. If there were locked files in the folder when it was deleted, the submit hangs the workflow with a comment in the submit task that states 'checked out files prevent submission.' We know about this situation and are able to deal with it. However...

When ever we submit a folder, even without any locked files, it still causes a conflict. Is this a bug in teamsite or is this the expected behavior? Thanks in advance for your input.

Regards,

nathan
washington DIS

Find more posts tagged with

Comments

Adam Stoller

Are you talking about submitting a brand new folder with brand new content - or a pre-existing folder with pre-existing content which may or may not be locked or modified in a different workarea?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

NathansDIS

Thx for your reply Fish-

If it is a new folder or an old folder, it doesn't seem to matter. The branches in question only have one workarea, so deleted folders are the only things that cause us conflicts. I'm sure it's not a locked file, because the comment in the submit task does not state 'checked out files prevent submitting' which indicates a locked file. Any other ideas about this behavior?

thx, nathan

Adam Stoller

No ideas - sorry - haven't been doing a lot of work in 6.x yet - a bit here and there but nothing concentrated (that should change soon though, hopefully). Perhaps someone else can chime in?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Teamsite does not version directories completely. So when a directory is deleted it is hard to tell if whats in staging is the same as whats in the workarea and hence teamsite used to err on the side of caution and throws a conflict for directory submissions. Prior to TS6.1 in some select cases a conflict was not thrown. However even in those select cases there were cases where genuine conflicts were not caught (which would result in someones work getting undone). To account for this from in TS6.1 Teamsite always flags directory deletions as conflicts. The submit will process if the overwrite flag is specified.

With teamsite 6.5, a scaled down verion of directory versioning was introduced wherein teamsite can more accurately detect directory conflicts and appropriately flags them. As a result from TS6.5 onwards not all directory deletions are flagged as conflicts. Only the genuine conflicts are so flagged. The reason I refer to this as a scaled down version of directory versioning is that not all versioning support is provided. For instance, it is still not possible to revert to older editions of directories etc.

Migrateduser

I have an instance right now with an empty deleted directory that throws a conflict and won't submit regardless of whether one chooses Override Conflicts with STAGING = yes, or even clicks Overwrite All on the conflict resolution dialog. I haven't tried an iwsubmit from the command line yet, so I think there may be cases that are more nuanced that what you detailed.

In any case, I'm glad to hear that it's fixed in 6.5. That alone is enough of a reason to upgrade.

gzevin

I had a similar posting quite a while ago.

You should check editions as well, there could locked files that you could have deleted ages ago and that are not visible either in STAGING or workareas...

in the end I had to resort to the ultimate solution - to recreate the branch.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

NathansDIS

I was able to create a workaround for this issue by setting my first submit task to transition to another submit task on failure that has the overwrite and skipconflicts flag set. This doesn't take care of the case when the deleted folder has a locked file in it, but it is better than a conflict on every deleted dir. This config only works for us because the branch has only one workarea. If you had multiple workareas, this would essentially ignore and overwrite all conflicts(probably a bad thing.) ;D

-Nathan
Washington DIS