Greetings Epic Games
It would be nice to get more source-control support, in particular I am interested in Microsoft’s Team Foundation Server.
Is this something you are looking at long-term or can we expect it in the month or two?
Thanks!
Best regards,
Pavel Popovciuc
On that note, it would be fantastic if we could get git support in-editor.
Also like to see native support for Git.
They could also include in the new project screen, download a project directly from a Web site (like git or bitbucket).
Without native support, how would I go about adding my repo to Bitbucket?
Hi Guys,
Internally we use Perforce for our source control, so the tools work with that and we test those workflows every day.
As far as other version control options, some of these would be good community projects, and it would be nice if we (Epic) could provide the most popular ones, however i’m not sure if we even know what is most popular among our users. Do you have insight?
As far as popularity goes I was actually surprised you guys included subversion support over git support, because git has clearly emerged as the source control of choice for opensource etc. Everyone i know moved away from subversion ages ago but maybe i just hang with the young crowd 
Yeah, I haven’t heard of SVN in a long time. Git is the way to go now.
Lets not forget Mercurial just yet :). Though yes due to GitHub’s popularity Git is the popular kid on the block.
Yep. I think Git is for sure the most popular version control tool. Now, also Visual Studio 2013 provides an out-of-the-box Git integration.
From what I understand (not being an experienced Git user!) Git has problems with lots of large binary files like textures and meshes, so we were hesitant to include editor support for it out of the box. I’d imagine it could work fine for smaller projects though!
SVN has two “advantages” respect to Git with binary files: 1) it allow to lock them with “svn lock” avoiding problematic merge conflicts and 2) it is a centralized version control system so it is not required to move around the whole project history. There is no problem with binary file as such. But because of point 1 it works better for small team.
There is an interesting discussion about git/svn comparison here.
I’ve started implementing a basic Mercurial source control provider, by basic I mean the idea is it will allow the diffing/adding/committing of assets, but things like pushing/pulling/branching etc. will be left to your Mercurial client of choice. Much the same could be done for Git. While storing large binary files in Mercurial/Git is liable to bloat the repository (unless you use an extension) it’s probably not a huge problem for small projects. For larger projects I think you could store code and blueprints in hg/git, and art assets in some more suitable location.
That was what i have been lead to believe as well.
The majority of the integration with any source control is in the Editor, so that you can use the editor and in the background it checks out what you need, adds files, etc… These files are all large binary files, and version controlling them will quickly cause your repository to grow to 10’s of gigabytes quickly, since small changes can cause all of a binary file to change.
If the version control system that is integrated into the editor doesn’t handle gig’s of files, or binary files well, it probably doesn’t make sense to spend the time on the editor integration.
If we are ill-informed and git handles large binary files well - we should consider adding some content to our github source
It’s true that Git handles binary files poorly, however with every project I’ve been on that uses it as the DVCS of choice we would usually adapt one of two workflows to handle the issue:
A) Have binary assets stored separately from the main repository, and copy them from elsewhere at the most convenient time (like, say, Dropbox) through a script.
B) Have a limited number of “stages” for binary asset integration. I.E., placement, prototype, final, making very limited changes in-between.
We would also prefer text serialization over binary serialization where available. Case in point, Unity. On a couple of projects, for Unity we’d set it up to serialize everything it could with text instead of a binary representation of, for example, scenes. For the likes of models and animations, typically collada was the format of choice given how well it works with the likes of Git.
There’s a few different extensions you can get for Git to help with handling binary files such as git-bin and git-media, but it’s important to note that these solutions don’t actually store the media files within the repository themselves but instead allow you to store them in another remote location.
That being said, Mercurial does have a mechanism built-in as of 2.0 that helps the situation a little bit, but even the official Mercurial documentation lists it as a feature of last resort. You can find more information about this feature in their Largefiles extension documentation.
Finally, storing binary files is typically not a good idea in any source version control system. This isn’t a problem that’s isolated to Git, but rather one that becomes much more noticeable with Git. Mercurial and even SVN don’t handle binary files very well either in a general context.
Or Mercurial. Sorry, but every GIT lover seems to think GIT is the only popular DVCS. Mercurial has just as equal a usage base, they just don’t fly banners for every single project using it ever.
A vote for native support of Mercurial! FYI, it supports big binary files via the standard “largefiles” extension (http://mercurial.selenic.com/wiki/LargefilesExtension).
Support for Bit Bucket would be nice.
Would it be possible to use git for source control and share the larger assets an other way, like a shared Dropbox folder? I’m not sure how that would work out, just an idea.
What would be nice is if Epic could do a video overview of how they go about using Perforce on a daily bases and how to go about setting up a Internet based server.
Disclaimer: I wrote the plugins that currently power the source control integration for Unreal Engine 4.
I have a rough draft of a blog post that tries to go into some detail about how one might implement different source control providers in the Editor - does this sound like something that might be useful to you guys?