Auto-Commit to SourceControl on Save Setting for Collections Doesn't Function

Development Pipeline & Plugins
, ,
1

The “Auto-Commit to SourceControl on Save” setting for collections is being overridden by a hardcoded bool in CollectionManager.cpp called “bForceCommitToRevisionControl”. This has the fun side-effect of spamming check-ins, bypassing our normal review processes, when using Private or Shared collections, rather than checking out the files and allowing us to commit the changes all at once.

In addition to the bug, it would be nice if the setting defaulted to false to avoid these issues. We’ve diverged the engine on multiple projects to disable the ability to auto-commit collections entirely.

Cheers!

2

Steps to Reproduce
Connect UE 5.5 to revision control. Uncheck the “Auto-Commit to SourceControl on Save” in the collections setting of editor preferences. Create a private or shared collection and add + remove items from it. Note the commits that are spammed into the connected repository.

3

Hi Robert,

The `bForceCommitToRevisionControl` boolean does cause some collection operations to auto commit despite the settings. However, it is not expected that adding or removing an asset to a collection would cause an auto-commit.

The operations which are expected to commit irrespective of the setting (current as 5.6-preview in github)

  • Creating a collection
  • Renaming a collection
  • Emptying a collection
  • Saving a collection
  • Saving the result of a search query as a collection

bForceCommitToRevisionControl should be false for the following operations:

  • Reparenting collection
  • Adding assets to collections
  • Removing assets from collection
  • Setting the collection color
  • When a redirector is within the collection and the redirector is deleted

Could you confirm that divergence in your branch leaves the bForceCommitToRevisionControl to false in the following functions:

  • FCollectionManager::AddToCollection
  • FCollectionContainer::RemoveFromCollection

(Note: 5.6-preview code has these functions at FCollectionContainer from commit 517f6573f680f4a5329d78fa6f2852eee6ba4006, so when upgrading you will need to move over any divergence to there)

The code should roughly look like this (taken from FCollectionManager::RemoveFromCollection)

constexpr bool bForceCommitToRevisionControl = false; if (!InternalSaveCollection(Guard, *CollectionRefPtr, OutError, bForceCommitToRevisionControl))Internally, FCollection::Save should check `bForceCommitToRevisionControl` in the following block

`if ( bUseSCC && (bForceCommitToRevisionControl || GetDefault()->bAutoCommitOnSave))
{
// Check in the file if the save was successful
if ( bSaveSuccessful )
{
if ( !CheckinCollection(AdditionalChangelistText, OutError) )
{
// …
bSaveSuccessful = false;
}
}

// If the save was not successful or the checkin failed, revert
if ( !bSaveSuccessful )
{
FText Unused;
if ( !RevertCollection(Unused) )
{
// …
}
}
}`You can put breakpoints into that block and determine what the value of bForceCommitToRevisionControl is and where the value may be coming from. This would help me track down why this might not be working.

The setting was chosen to be kept as defaulted to true because this has been the default behaviour for quite some time. The reason we chose this was to deal with the case where multiple people are editing the same collection and they have both checked it out, if auto-commit is false, then it could be up to the user to merge the changes which is not always easily done by all users depending on their experience with external merge tools. If everyone on the team is comfortable with this situation, then disabling auto-commit is a good course of action to help mitigate some of the stalls due to waiting for perforce servers to respond.

Since you maintain a diverged engine, you can change the default value of bForceCommitToRevisionControl in Config/BaseEditorSettings.ini. The following should do it.

[/Script/CollectionSettings] bAutoCommitOnSave=FalseLet me know where you get with determining the source of bForceCommitToRevisionControl and we can go from there.

Logan

4

Thanks for checking Robert.

As far as I know, 5.5 and 5.6 should have the same behaviour (based on my cursory glance at the diffs).

I’ll take into consideration some of these use cases next time we have a chance to improve collections in the future. Emptying is an operation that strikes me as not needing commits to occur (it is a special case of removing assets from a collection).

The divergence you are maintaining, how extensive is it? Is it switching the bForceCommitToSourceControl to false for all cases or is there something more?

5

Yup! I can confirm that the add/remove operations don’t exhibit this behaviour. One of the automated operations I was performing was clearing one or more collections before rebuilding them (or creating them). I think it’s still unexpected that there are operations that automatically commit themselves, even if you’ve set that option to false in project settings. Creating, renaming, and emptying are all things that we do via automation that we don’t want to spam the repository with. We still want to mark collections for add and check them out, but automatically committing changes and bypassing our normal preflight checklist is a big problem for us.

I was rather excited about having a setting so that I could stop maintaining this divergence, but I don’t think it will serve our needs as-is. Simple enough to port over when we upgrade to 5.6, so thanks for the heads up!

6

I added an early return to FCollection::CheckinCollection(), after it performs all of its validation steps, right before it generates the CL summary. A bit heavy handed, but easy enough to maintain.