Announcement

Collapse
No announcement yet.

Additional Source Control providers support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Additional Source Control providers support

    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

    #2
    On that note, it would be *fantastic* if we could get git support in-editor.

    Comment


      #3
      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).
      [Compatibility List] Unreal 4 - Hardware Feedback (Leave your feedback on how the Unreal runs on your computer)

      Comment


        #4
        Without native support, how would I go about adding my repo to Bitbucket?

        Comment


          #5
          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?

          Comment


            #6
            Originally posted by Paul Oliver View Post
            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

            Comment


              #7
              Yeah, I haven't heard of SVN in a long time. Git is the way to go now.

              Comment


                #8
                Lets not forget Mercurial just yet . Though yes due to GitHub's popularity Git is the popular kid on the block.
                Contact: enlight in #unrealengine IRC channel on Freenode, or @macagonator on Twitter

                Comment


                  #9
                  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.
                  Game and AI developer.
                  Twitter: @thek3nger

                  Comment


                    #10
                    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!
                    Lead Programmer - UE4 Animation/Physics/Audio Team - Epic Games
                    Twitter: @EpicJamesG

                    Comment


                      #11
                      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.
                      Game and AI developer.
                      Twitter: @thek3nger

                      Comment


                        #12
                        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.
                        Contact: enlight in #unrealengine IRC channel on Freenode, or @macagonator on Twitter

                        Comment


                          #13
                          Originally posted by JamesG View Post
                          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!
                          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 :-)

                          Comment


                            #14
                            Originally posted by Paul Oliver View Post
                            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.
                            Last edited by Geenz; 03-30-2014, 07:41 PM.

                            Comment


                              #15
                              Originally posted by jaran View Post
                              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
                              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.

                              Comment

                              Working...
                              X