Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Files still left in Changed Files list after committing a scoped application to source control - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Files still left in Changed Files list after committing a scoped application to source control
KB0695379

Files still left in Changed Files list after committing a scoped application to source control


831 Views Last updated : Apr 7, 2024 public Copy Permalink
KB Summary by Now Assist

Issue

Symptoms


After using the Commit Changes feature in the Source Control menu in Studio, the commit completes successfully, but some of the changed files are still appearing in the list and the Commit Changes option is still available.

Release


All Supported Releases

Cause


When an application is committed to source control, the system searches for sys_update_xml records in order to determine what local changes are being committed. When the commit is finished, the system deletes these sys_update_xml records. However, the system will only remove them if they are inside a valid update set that is part of the application.

If files are still appearing in this list after committing, it indicates an issue with the update set they are in. Find these updates by going to the sys_update_xml table and searching for records where the Application field is equal to the affected application. Then, investigate the update sets that these updates are in. If the Application field on these update sets does not contain a valid value, or if they are part of another application, they will not be cleaned up.

Usually, the updates are in the wrong update set due to being moved manually. It is strongly discouraged to move updates manually between update sets.

Resolution


In order to resolve the issue and remove the changes from the Changed Files list, you must manually delete the sys_update_xml records for these files. Alternatively, you can move them into a valid update set that is part of the application, and then commit again to have the system clean them up.


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.