Hi guys. I’m just getting started with all things github, but I figured I would just dive in and see if I could swim. I made a repo, copied an existing project into that repo directory, then committed and published it. All seems fine. Files are in the repo, I can modify files in UE and then update via git, etc. However, when I try to use the in-editor git support via the new beta git plugin, I am getting the message:
Error You should check out a working copy into your project directory.
Error Project is not part of a Git working copy.
Did I do something wrong in the order I created things? I made the repo first, copied my project into that repo, committed and published the repo, and then opened the project from the repo folder. I’m also seeing an error:
Error fatal: Not a git repository: ‘"/Users/jj/Dev/gitHub/mepgencontent/.git’
Is there a version mismatch? Or possibly a “I’m on a mac” situation? The wiki tutorial doesn’t really go into this level of detail. Aside from “Turn the plugin on”, it doesn’t really cover much at all as far as the nitty gritty step by step how to. Is there a different/better “How To Use Git inside UE 4.7” tutorial out there?
Hmm… I’m discovering that perhaps git isn’t the best system for sharing engine content, specifically art assets. Especially with github’s 60MB file size limit. I do want to have some sort of revision control system in place though. Dropbox works, but it seems less then perfect. I find that if I have dropbox actively synching while working in the editor, I crash a lot. This is just since 4.7 though so I’m betting it’s the new auto-import seeing all of dropbox’s temp files and freaking out. If I pause dropbox, I don’t crash.
So, I guess my question now is, for indie/very small scale collaboration, what are people using to share projects? Cheers,
Any distributed version control system(git, mercurial, etc) are inherently ill-suited to game development is you want/need to include assets/binary data.
Subversion or Perforce are de-facto industry standards in terms of version control/project access because centralized version control systems don’t have this limitation when it comes to file sizes and such.
That is inaccurate. SVN doesn’t do well with binary assets, it just stores them. Perforce does, and that’s one of the reasons it’s so pricey. There’s nothing about centralized versus decentralized that stops them from handling binary assets - it’s the nature of revision control systems that binaries are hard to do (and often pointless.)
That said, git has lots of ways to handle binaries and now Github does it built in with Git LFS.
Well, Subversion does handle binary files effectively (with binary diff algorithms). But sometimes binary diff are not good enough (with compressed or crypted data) We’ve use it in the industry with GBs of data with no problems.
Perforce is said to be more efficient on the subject, for more or bigger files up to TBs if I understand well.
Also, Git does also store binary files very effectively, so no real problem with that. The big problem with distributed control is that every client get all the version of all the files (albeit compressed).
In a client/server centralized SCM model, only the server needs to keep all versions, clients does only checkout the appropriate revision of the files.
Hashing a binary file is not diffing it. When was the last time you merged a binary in SVN?
Git does NOT store binary files effectively. That is why there are something like 6 different plugins for git that allow it to effectively do so. Those extensions deal with the issues that git has with binary files.
To be clearer: You probably shouldn’t be putting binary files in revision control. They should really be in some sort of binary artifact repo. A lot of the git plugins basically do that seamlessly. It’s what Git LFS does.
Storing binaries in SVN will mean your repo just gets bigger and bigger. There’s no way to remove old versions of files. Don’t do it. Yes, SVN does do binary deltas. But it stores all of them, forever.
Backov, I agree with your conclusion: no source control CAN do merging of binary assets by themself, so most binary files should not be there.
But sadly, binary merging is no more feasible with a binary artifact repo.
Unreal Engine is offering a merge tool for Blueprints, so there, binary or not, it is more feasible to solve conflict on those files (not for Mesh or Textures…)
(My point was only on storing binary files, where Git use the same class of diffing algorithm as SVN: git extensions (git-annex, git-media, github LFS) are there to support your point => binary CAN be stored in source control, but mostly SHOULD not. And distributed systems suffer more than centralized one, and so those extension offer support for specialized binary artifact repo).
You’re right - it’s not a feature we will ever have as programmers. Except, as you mentioned, in specialized cases like BP. But in the case of BP, they can do that because it’s really just logic that can be read and compared in a sensible manner. It’s just stored in binary.