• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

GMS 2.3+ Source control refresh issue

peetj

Member
Hi,

I am currently setting up 25 students in a Bitbucket workspace so that we can develop in teams. We are using the SCM in GMS2. In my testing I have found that if person A pushes a commit and person B pulls it, the Asset Browser is not refreshing. I know the change has been pulled by viewing the History. The only way I can see the change is by restarting GMS2 - not ideal. Closing and re-opening the A.Browser does not do the trick.

Is there a way of refreshing the Asset Browser without a restart?

Many thanks

Pete...
 

Roldy

Member
Make sure the File Watcher setting is activated.
File Watcher

GMS2 will be scanning files for external changes. It may take longer than expected.

Personally, no matter if I am using Visual Studio, Unity, GMS2 or even Notepad I tend to close the application before making external changes to the files. Bad things tend to happen.

But theoretically it should work, no problems.

Another work around would be to File->Open and just reopen the project. This may be faster than a full restart.

One of the biggest problems that you can run into when working with assets that are not LOCKED in version control is when someone pushes a change to an asset that another user has active changes to in memory (not on file). When that user does a pull without saving their changes to file, no merge or conflict will be detected; however, the changes in memory very well may be lost or SHOULD cause merge conflicts. This can cause lost work and or very confusing merges. Typically either working with a VCS that handles locking asset checkouts or simply closing applications and saving changes before pulls will avoid this.
 
Last edited:

peetj

Member
Make sure the File Watcher setting is activated.
File Watcher

GMS2 will be scanning files for external changes. It may take longer than expected.

Personally, no matter if I am using Visual Studio, Unity, GMS2 or even Notepad I tend to close the application before making external changes to the files. Bad things tend to happen.

But theoretically it should work, no problems.

Another work around would be to File->Open and just reopen the project. This may be faster than a full restart.

One of the biggest problems that you can run into when working with assets that are not LOCKED in version control is when someone pushes a change to an asset that another user has active changes to in memory (not on file). When that user does a pull without saving their changes to file, no merge or conflict will be detected; however, the changes in memory very well may be lost or SHOULD cause merge conflicts. This can cause lost work and or very confusing merges. Typically either working with a VCS that handles locking asset checkouts or simply closing applications and saving changes before pulls will avoid this.
Thanks Roldy - I'll checkout the open project trick. I think that would work. Closing & opening the software is silly. There should be a refresh in the code. I was expecting the file scanner to kick in but it didn't.
I thought the world moved on from locking files 10 years ago ;).

Noted - when conflicts occur GMS2 doesn't really have the right tools to fix it well. It is possible though after testing it. I think my students will struggle so I'll advise them to work on separate assets.

Many thanks

Pete....
 
Top