Reset STAGING area conflict automatically

Hi all, is there a command, a script or a task to reset conflict automatically and overwrite all the conflict without stop the flow to move a file from a development are to the production area? I use Dreamweaver to work directly in the WORKAREA of a site but I don't understand the use of STAGING area.

Find more posts tagged with

Comments

Bubas_IWOV

Hi,

Can you explain a litle bit more the process of what you are trying to do?

Staging area is meant to be used as you image of production. So you use the Workarea for development and then you submit to Staging to create a version of your file and then deploy to production from there.
you can take a step forward and once your file is in the Staging area you can cut an Edition of your site.

And yes there are ways to overwrite confilits, you can use the out of the box submit workflow and select overwrite conflits or you can use the command line.

Explain a litle more of what you are trying to achieve and i help you.

B

nipper

Hi all, is there a command, a script or a task to reset conflict automatically and overwrite all the conflict without stop the flow to move a file from a development are to the production area? I use Dreamweaver to work directly in the WORKAREA of a site but I don't understand the use of STAGING area.

You can set the submit to overwrite all changes. That is a trivial change. Obviously there is another issue that someone does not understand.

What workflow are you using ? Who set it up ? If it is one of the out of the box workflows, then there is a parameter file to change.

bigangels

Hi,
OK, I'm new in Teamsite so I understand later that the STAGING area is a step before moving in production. The problem I've is that at a certain point, I don't know when, the staging area conflict with workarea even if I didn't change anything in the last month. What is changing is just only three difference that are in the Modified by item (WORKAREA = root and STAGINAREA = myUserID), in Version (WORKAREA = 0+ and STAGINAREA = 4) and in permissions (WORKAREA = rwxrwxr-x and STAGINAREA = rw-rw-r-- ). But the size and the time are exaclty the same.

What do you mean for "you can take a step forward and once your file is in the Staging area you can cut an Edition of your site"

I mean what it's correct for me is what I've in the WORKAREA as I use to change the file directly.

Also I cannot use the "Overwrite all" button or the command line as I'm not admin and I can just submit file. (I think :-) )

nipper

But that is what you are not understanding. You are working from version 0 which means a clean slate. The staging area has 4 versions checked in. That is a conflict. If I am working in a WA that is up to date with staging, both numbers should be 4 (or 4+ in the WA which means I have changed it)

Is anyone (or a tool) creating .bak files ? does TS show any deleted files ? The only time I have seen this happen is when someone or something copies the current to a .old and creates a new file. There is no real content change, but TS sees a new file and assumes it starts at 0.

Adam Stoller

Hi,
OK, I'm new in Teamsite so I understand later that the STAGING area is a step before moving in production. The problem I've is that at a certain point, I don't know when, the staging area conflict with workarea even if I didn't change anything in the last month. What is changing is just only three difference that are in the Modified by item (WORKAREA = root and STAGINAREA = myUserID), in Version (WORKAREA = 0+ and STAGINAREA = 4) and in permissions (WORKAREA = rwxrwxr-x and STAGINAREA = rw-rw-r-- ). But the size and the time are exaclty the same.

What do you mean for "you can take a step forward and once your file is in the Staging area you can cut an Edition of your site"

I mean what it's correct for me is what I've in the WORKAREA as I use to change the file directly.

Also I cannot use the "Overwrite all" button or the command line as I'm not admin and I can just submit file. (I think :-) )

Nipper has already outlined the issue surrounding how this problem is likely to occur. I can only assume from your statements that you are logged in as Author - if that's the case I'm not entirely sure what to do (I haven't been limited to the Author role in a looooooong time and don't have a system to play with right now) - but you could try:

Perhaps someone else who uses DreamWeaver in a similar manner might be able to shed some light?

bigangels

Hi ghoti and nipper,
thank for your explanation. I think it's more clear now. In the last 2 month we upgrade our webserver to WebSphere 6 from version 4. This means that we have (I think as I'm not the Server Manager) in few word:

1) Stop Teamsite
2) deploy the .EAR file of our website to the new WebSphere 6 instance
3) Restart Teamsite

May be on point 2 when we redeploy the website on Websphere 6 the file deployed in the WA are "NEW" (so Teamsite assign 0 to them) and this could explain why we have so much conflict.

Is that correct?

bigangels

Hi ghoti,
I'm logged as Author, and I'm not able to use the "Overwrite all" button. I have the window with the list of conflict and I can click on "Overwrite all" button but I receive the following message: "Cannot retry submit for Submit (873465) because the task is not active". Also I've Retry Submit button, but it doesn't works as the result is a new conflict.

Adam Stoller

Hi ghoti,
I'm logged as Author, and I'm not able to use the "Overwrite all" button. I have the window with the list of conflict and I can click on "Overwrite all" button but I receive the following message: "Cannot retry submit for Submit (873465) because the task is not active". Also I've Retry Submit button, but it doesn't works as the result is a new conflict.

My suggestions were in the view point of doing those things *before* trying to initiate the submit workflow. Though if the conflict window gives you the ability to overwrite - then that *should* be sufficient.

At this point I suggest killing all these jobs that are in conflict and attempting to resolve the problem within the workarea before trying to submit again.

The file as it exists on the web server or app server is not an issue.
The file as it exists within TeamSite in the workarea is the issue.
Something in the way that you are editing these files is causing TeamSite to see your modified file as a new file (0+) instead of a modified version file (4+)