Timeline for Version control for game development - issues and solutions?
Current License: CC BY-SA 3.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 28, 2019 at 22:43 | comment | added | Basic | Yeah, sorry, git jsut isn't fit for purpose here. Even with the LFS (large file) extension, it rapidly bloats to the point where a clone can take hours, and some operations are painfully slow. | |
| Mar 19, 2016 at 13:51 | comment | added | AhiyaHiya | I use git at work (not game dev), but for game development, it is not a good choice. Git is designed for handling source code and that's it. Using submodules for binaries are if'y at best. If you do make the mistake of putting many binaries over 10MB into git, the git system quickly explodes in size and using git becomes horribly slow. In game development you have many different assets and you need a reliable way to package everything at a particular revision of code and assets; git cannot do this nor was it designed to. As for git lfs, only seasoned DevOps people should mess with that option. | |
| Dec 17, 2013 at 6:12 | history | edited | congusbongus | CC BY-SA 3.0 |
update broken link
|
| Nov 18, 2013 at 22:53 | comment | added | guysherman | The main problem I have with using git for games is the large files. I have worked on several projects recently where the repository took up ~12 GB on disk, and ~9 GB of that was the .git directory. I have seen scenarios where art assets are in a SVN repository that sits below the git repo, and is ignored by git. This works reasonably, because it means you can "embed" a particular branch of your art assets in your repository, and have a robust process for putting new assets in the hands of developers. It needs a bit more automation though. | |
| Oct 29, 2013 at 13:39 | comment | added | Andreas | Git submodules are pinned to a specific commit sha and not to HEAD, so your (junior) coders will drive you insane. | |
| Oct 29, 2013 at 13:37 | comment | added | Andreas | Git doesn't support locking, so your artists will go insane ;) | |
| Feb 13, 2013 at 14:05 | comment | added | JackLeo | For mercurial bigFile extension equivalent there is git-annex.branchable.com | |
| Dec 21, 2011 at 19:50 | comment | added | idbrii | @AlexSchearer: Submodules are a good solution, but then you have one git submodule with every version of assets where one file may be 1 GB (and they don't compress well since their deltas are the whole file). This doesn't impact your main repo, but it may grow absurdly over the course of a project. You also have no ability to lock a binary file (so people don't start editing files that can't be merged). It seems like it would be ideal if you could have a svn submodule that was an svn repo. (I guess you could use git-svn so you can lock, but you'd still have all of that history.) | |
| Sep 26, 2010 at 22:09 | history | edited | Ricket | CC BY-SA 2.5 |
fixed capitalization. Git is not an acronym, and if anything it may even be all lowercase (as it is spelled in the top left of the homepage).
|
| Aug 17, 2010 at 22:51 | history | edited | David McGraw | CC BY-SA 2.5 |
added 9 characters in body
|
| Aug 6, 2010 at 17:07 | comment | added | coderanger | My big vote for Git (or hg if you prefer), once you have more than 3 maintenance branches SVN gets absolutely impossible to manage. | |
| Jul 26, 2010 at 20:43 | comment | added | Alex Schearer | Why not use Git's submodules to manage the binary files? That way you could create separate repositories as needed and then tie them together using submodules. Any future changes in the main repository should not affect the submodules. | |
| Jul 17, 2010 at 20:49 | comment | added | Spoike | Git is good and all but when it comes to handling big graphic or music assets, such as larger than 100's of MB, it becomes noticably slow at commits and check-outs. At the moment Mercurial, the contender to Git, has a "big files" extension that addresses this specific issue. If you have a game project that doesn't have a lot of assets you could give Git a try. | |
| Jul 17, 2010 at 1:12 | comment | added | David McGraw | @D. Hayes: I believe there are initial costs (checkouts and what not), but after that it is faster than other solutions. | |
| Jul 17, 2010 at 0:57 | comment | added | drhayes | I've heard that Git and Mercurial both suffer when shoving very large files into them. Any truth to that rumor from people with more experience than me? | |
| Jul 16, 2010 at 17:52 | history | edited | Cyclops | CC BY-SA 2.5 |
added URL
|
| Jul 16, 2010 at 7:39 | comment | added | tenpn | no VCS in general | |
| Jul 15, 2010 at 19:21 | history | edited | David McGraw | CC BY-SA 2.5 |
reorganize paragraphs
|
| Jul 15, 2010 at 19:12 | history | edited | Rachel Blum | CC BY-SA 2.5 |
Added a comment on it keeping the whole history
|
| Jul 15, 2010 at 19:08 | comment | added | Cyclops | @tenpn, is that a feature of distributed VCS in general, or just Git? | |
| Jul 15, 2010 at 18:58 | comment | added | tenpn | I love the idea of hierarchy of branches allowing QA to test changes before they make it to mainline, or easy creation and validation of demos. | |
| Jul 15, 2010 at 18:57 | history | edited | Cyclops | CC BY-SA 2.5 |
added 9 characters in body
|
| Jul 15, 2010 at 18:51 | history | answered | David McGraw | CC BY-SA 2.5 |