I have a custom application scope where we needed to add a few bug fixes.
So we create an Update Set in the scoped application and commited this to the other instances.
The problem is, this update set contained Inserts of new records. So when we now publish the proper version it generated skipped records. And we can't revert to base because there is no base to revert to.
Update:
After further investigation this is intended behavior. Because for proper Source Control, an update from an Update Set can't and shouldn't qualify as a Base Version.
The problem in my case was that the Update Set contained records never published by the application.
So when the final version was Published and it generated skipped records, there was no Base version to revert to.
The only fix was to force a newer update in DEV of these files and Publish so there was a qualified Base Version.
Then I looked through all the skipped records and reverted to base.
So now the state of the application is correct.
Sorry, let me show an example of a skipped record.
This is a field label, but it's the same concept
If I click Resolve Conflict or click Revert to Base System I get the following message:
Because there is no base version.
If I open the record in question and check the Versions, I see there's only one version, the one from the Update Set.
In other words, this Update Set contained an Insert of this record, and so it apparently doesn't qualify as a Base Version.
Just to verify I went back to DEV and made an update to one of these skipped records (a client script) and published again. It now allows me to revert back to base and Version history looks like this:
Edit:
I seem to have solved the issue by manually updating each record that produced the skipped record. And publish the application so a proper base version exists. And then revert to it.
I have seen this scenario before with files missing a Base Version, that's why I decided to finally create a post about it and dive into it.
My conclusion is to avoid Update Sets for Custom Applications if possible, if we want to retain proper source control. And instead use branching and stashing if we need to publish incremental fixes.
Sorry, let me show an example of a skipped record.
This is a field label, but it's the same concept
If I click Resolve Conflict or click Revert to Base System I get the following message:
Because there is no base version.
If I open the record in question and check the Versions, I see there's only one version, the one from the Update Set.
In other words, this Update Set contained an Insert of this record, and so it apparently doesn't qualify as a Base Version.
Just to verify I went back to DEV and made an update to one of these skipped records (a client script) and published again. It now allows me to revert back to base and Version history looks like this:
Edit:
I seem to have solved the issue by manually updating each record that produced the skipped record. And publish the application so a proper base version exists. And then revert to it.
I have seen this scenario before with files missing a Base Version, that's why I decided to finally create a post about it and dive into it.
My conclusion is to avoid Update Sets for Custom Applications if possible, if we want to retain proper source control. And instead use branching and stashing if we need to publish incremental fixes.
