- If you can’t merge it, you can’t use it. Ever solved a merge conflict on a xib file? Me neither. So xib’s weren’t allowed. Which suits me - I never liked xibs, story boards, all that junk.
- Same with merge conflicts on .pbxproj files - these files weren’t checked into source control. Instead, there’s a Google open-source tool called GYP that generates your Xcode project from a JSON recipe and recursively searching the folders for source files. Worked pretty well, except that GYP is poorly documented and not able to perform certain project configurations (eg per-file -fno-objc-arc).
This seems to make a create deal of sense to me but it's the first time I've come across the idea explicitly stated. If it can't be merged, it shouldn't be in source control. So what do you do with those binary blobs that are required by your build process - the answer suggested is to generate the binary blobs from something that can be merged. This sounds like an excellent clean way of working.
If I reflect on some of my own my own source control repos, I probably have a few things in there that would benefit from being generated.
Of course for game development this needs balancing with practicality, do we want to have textures in markup? It would ensure we can always produce the required texture but the file sizes would explode! Source files for textures are usually PSD and have mutiple layers and history, even as a binary they can easily become 100 of megabytes in size. I know a number of studios have the binary game assets in a seperate source control program which might be the answer.
Game assets definitely benefit from the ability to roll back to earlier versions but trying to force it into a text-based format is usually worthless, a 3d artist isn't going to be able to merge changes to a Maya file from another artist in a standard merge tool. Though it there was more graphical merge tool, I see no reason why it couldn't work.
No comments:
Post a Comment