3

A member of our team is really wanting to use Visual Studio Team Services over TortoiseSVN or Proforce for storing our assets on. I've looked over the source control options provided on the Unreal Documentation website and saw that ProForce and TortoiseSVN are supported at this time. I have also seen Visual Studio's documentation over "large files" and have noted that binaries/libraries apparently don't play nice with VSTS.

I'm worried about how Blueprints or other art assets will behave down the line of development.

I am wondering if it is wise to use the Team Services Git platform, over the other two source control methods. Do you believe that blueprints and art assets will behave in the long term? Or is this a horrendously bad idea?

cfact
  • 33
  • 2
  • Possible duplicate of [Is git good with binary files?](https://stackoverflow.com/questions/4697216/is-git-good-with-binary-files) – max630 Sep 12 '17 at 20:30
  • Well most of my concern is over Blueprints and other assets involved in UE4 and if VSTS is going to work well with these through development of a game on that engine. I mention the binary documentation in order to confirm what documentation I had reviewed. – cfact Sep 14 '17 at 02:59

2 Answers2

2

There is no problem here, and definitely nothing related to VSTS -- Git in VSTS is just Git, the same as you'd find on any other Git hosting platform.

VSTS supports Git LFS for versioning large binary assets.

You can also use a TFVC repository, which is a centralized version control model similar to SVN.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
2

I am the author of the Git Source Control Provider plugin in Unreal Engine 4.

Git LFS with VSTS is definitely a working solution.

But it is not currently supporting Git LFS 2 file Locking mechanism, so it is not on par with Perforce or SVN: it is okay for a small team but will not scale well if you want multiple person to work on the same Blueprints (you will have to solve conflicts).

SRombauts
  • 438
  • 3
  • 12
  • So a Team of 3-5 may be fine, but the more we add and the more likely the Blueprints will corrupt? Or is it a case of just making certain people are locking the Blueprint they are working on in order to prevent conflicts? – cfact Sep 14 '17 at 02:57
  • The problem is Git itself offers no way to lock a Blueprint, so two persons can modify it, and even commit it locally, but the second one that will try to push to the central repository will get a conflict : he will have to either revert the change he made, or those of the first guy! so you will have to rely on team communications to avoid working on the same things, instead of using the source control for this synchronisation. (also I am working on File Locking through Git LFS 2 but I don't know when it will be supported) – SRombauts Sep 14 '17 at 06:47