Modified files and 'different' files - what's the difference?
After an hour or two of DevNet and Support site snooping, I thought I'd post here.
I've managed to manipulate some assets in workarea that leave a set of files in a workarea as 'not modified', but different than the files in the Staging portion of the branch. I'm looking to understand why.
Here's the scenario:
We use some of our TeamSite branches much as one might use Subversion:
- create a 'dev' workarea for project work based on the current set of Staging assets.
- development takes place in the dev WA. When development is done, 'list modified' shows the assets that have been modified in the dev WA.
- use 'copy to' to merge the modified assets into another 'int' WA ('int' for integration'.) At this point, the assets in the dev and int WAs both appear as modified.
- run a workflow out out of the int WA of these modified assets.
- when the assets get approved for, and deployed to, production, do a submit of the assets from the int WA into Staging. At this point, all of the job's assets no longer appear as modified in either the dev or int WAs.
Pretty straight forward and works nicely for us.
Here's what I did recently that made me post this question:
One of our updates to production broke the site. 99% of the time, we figure out what the problem is and run another workflow based on the process outlined above. This time, we couldn't figure out what the problem was, so we decided to roll back the update. Here's how I did it:
- I renamed the int WA to int_bak.
- I created a new int WA based on the current set of files in Staging, so when I started, there were no modified files in the int WA.
- I compared the new int WA to the Edition that contained the pre-problem assets. I copied the files shown as different from that Edition into the int WA. At this time, I had the pre-problem set of assets showing as modified in the int WA.
- I created a job from the int WA's set of modified files and pushed it out to production, effectively rolling back production and fixing the problem. Pushing it to production also submitted these older versions of the assets into Staging once again, so Staging and the int WA lined up just fine - no modified files showing in the int WA.
This all went as planned: get the old, good version of the files into a WA and roll them out to production. The 'bad' version of these assets is now in the original dev WA and in the Edition that was cut when they were pushed out. The Edition history reflects all this activity nicely, and the int WA is once again ready to receive merges from dev WAs.
Here's the mystery:
After all of the above activity, the dev WA still has the original set of 'bad' assets in it. And, if I do a compare of the dev WA with Staging, it detects that they're there. BUT, those assets no longer show up as 'modified'.
I understand that, when the assets first went to production, they lost their modified status, but I would expect that they might again become modifed once I pushed the previous version through the int WA and workflow.
I'm not really surprised at this behavior (after all these years, some aspects of locking and version history remain as voodoo to me), but I'd like to understand better what triggers the modified status and why the above activity doesn't.
Ideas, conjectures, some FMs to RT?
Thanks!
Wally Box
Nike, Inc.