Source control refresh issue

[peetj]

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]

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.

 

[peetj]

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....