Finding the right directory structure for version control

Question

Recently I've started thinking about how to layout the directory structure for my game engine. And well, I kinda hit a little snag.

There's going to be 2 people working on this project. Me and one of my friends. The problem is how do I do the layout of the directories so that it works nicely with version control (I'm using Plastic SCM. It has really nice features).

I'm thinking of dividing it up into 3 separate things:

1. A source code respository for storing all the C++ code

2. An exported assets repo where my friend can store all his exported data. (Exported as in final version that can be used by the engine).

3. And a raw assets directory where all my friends raw assets go into. These include stuff like psd files and mb files for easier backup and versioning.

What do you think of this structure? Any comments are welcome. I'm really down in the dirt with this one.

Answer 1

That's quite neat and clean. Just don't mess with different repos, make this separate directories at the root of your repo. This will of course evolve with your project, but as a startup layout this is way enough.

Your exported assets directory should probably be excluded from version control. It might be a good idea to have a separate "exported code" directory (object files + symbols + executables), to exclude from version control as well.

So, for instance, something like that:

repo
├── code
├── assets
├── export *
│   ├── code
│   └── assets

* Excluded from source control

It's apparently straightforward to exclude files/directory from version control with Plastic SCM, by using an ignore.conf file.

Answer 2

Let's get to roots of SCM - it is for sources. Now sources are not only text files, they are everything that you use as a source (source codes, scripts, PSD files, sounds). Everything that can be repeatedly generated are not sources (spritesheets, executables, resource packages).

You need to store all sources in one repository for the sake of consistency. Because each and every revision ought to be self-sufficient. You also need to have build scripts to produce application and all its assets from sources. Builds are not stored in SCM because you can always regenerate them.

EDIT: Once you put size out of the question, it makes sense to keep all sources in SCM because it's quite often when engine behavior depends on lookup textures, models sizes and shapes, assets count and location (also think TDD). When you have source codes revision A you ought to be very confident in your engine to allow it to work with any other assets revision. Otherwise you need to make a tie that code A works only with assets A, B-B, C-F etc.. and then when you rollback the code you need to rollback assets as well. That ruins SCM idea.

From practice: we were storing paletted textures, but since r2879 we switched our format to full-color textures. Having source textures (some unchanged since r1000) and generation scripts under SCM we don't have a problem of finding right assets/exe combo.

Answer 3

I would recommend using Trunk-Branches-Tags as your top level. Branching is invaluable for experimentation. I am not familiar with Plastic SCM, but my experience with Subversion is that you need to plan for these needs from the outset. Then under the trunk you can set up your files. Otherwise, as for binaries, I like to store the optimized final format and the most up to date source(photoshop, raw video, etc.,) in my repository. The main reason is that most of my tools support Subversion.