What should be stored in a repository?

Started by
21 comments, last by Mybowlcut 12 years, 10 months ago
I'm currently trying to determine what should be kept in the repository for a typical game.

As I understand it, the code and art/music/general game assets should be hosted, but what about the:

  • Project files for the code?
  • Third party libraries?


Are these things that should be hosted or should team members download/create them themselves locally?

Cheers.

Advertisement

I'm currently trying to determine what should be kept in the repository for a typical game.

As I understand it, the code and art/music/general game assets should be hosted, but what about the:

  • Project files for the code?
  • Third party libraries?


Are these things that should be hosted or should team members download/create them themselves locally?

Cheers.



The way I do it is ALL code files (even third party, unless they have a repository that I can update from then I use it.) and project files are kept. If the third party libraries aren't source code, I include the dlls etc out of the box. IMO a project should be compilable after downloading from a repository.

I then use dropbox.com and set it up as the media folder, so assets can just get stored there and iterations are put up and automatically downloaded to the local media folder.

It's simple it works and is free.

Engineering Manager at Deloitte Australia


The way I do it is ALL code files (even third party, unless they have a repository that I can update from then I use it.) and project files are kept. If the third party libraries aren't source code, I include the dlls etc out of the box. IMO a project should be compilable after downloading from a repository.

I then use dropbox.com and set it up as the media folder, so assets can just get stored there and iterations are put up and automatically downloaded to the local media folder.

It's simple it works and is free.

Sounds good. Not sure what you mean regarding the dropbox thing though. How does that work? I was thinking just plop the assets in the repository also..

When someone joins a project, they should be able to download from the repo everything they need to build the game from scratch (besides software tool installations like Visual Studio).
[hr]
DropBox is kinda like another type of repository. It's as if he's got his code in one repo and his assets in another repo.

When someone joins a project, they should be able to download from the repo everything they need to build the game from scratch (besides software tool installations like Visual Studio).
[hr]
DropBox is kinda like another type of repository. It's as if he's got his code in one repo and his assets in another repo.

Ah, I see.

What about the scenario where a library like SFML comes packaged for VS2005 & VS2008? Can we use different IDEs and just not put the project files under source control?

For most professional environments you should have EVERYTHING necessary to recover the system.

If you are only storing the build system itself you can test it easily enough:
  • Start a clean install of the OS.
  • Install the repository client.
  • Sync. (This can be in a separate branch within the system)
  • Disconnect from the network (just to make sure you aren't relying on something remotely)
  • Run the build script with a single button click or single batch file, and no other options.
  • Game should build completely without human intervention.

Note that this does NOT include things like "install the IDE", or "Install photoshop". All the executables and compilers and libraries and other neccessary items should be directly available within the tree.
There are also strong arguments for including copies of the tools necessary for creating and editing any binary file. For example, your art modeling tools. There is typically very little difference between keeping the install discs on a network location that is archived or in a versioning system that is also archived. This applies for all software, including Photoshop and Visual Studio, all the way to the versioning system tools themselves.

Since these files are not necessary for the build, you can give them a separate install script.

With that in place, you can rebuild any type of machine with:
  • Start a clean install of the OS.
  • Install the repository client.
  • Sync. (The install tools can be in a separate branch so they aren't on all machines all the time.)
  • Disconnect from the network (just to make sure you aren't relying on something remotely)
  • Use a single batch file like InstallEngineer or InstallAritist or InstallBuildMachine.
  • After pressing no other buttons, your machine should churn and run install scripts and soon be ready for use

If you can't do single-click install or a single-click build, then you have too much room for error when you need to recover your project years from now.
Thanks for the reply frob.

Does that mean the developers must be using the same IDE? I take it that you'd consider project files as necessary items in a repository.

Does that mean the developers must be using the same IDE? I take it that you'd consider project files as necessary items in a repository.
On every project I've worked on, there has been a standard set of tools. When it comes time to upgrade (e.g. VS2008 -> VS 2010), the whole team upgrades at the same time.


Project files should be in the repo -- unless you are automatically generating your project files with something like CMake, in which case you'd store your cmake project files instead of your generated project files.

[quote name='Mybowlcut' timestamp='1306188695' post='4814775']Does that mean the developers must be using the same IDE? I take it that you'd consider project files as necessary items in a repository.
On every project I've worked on, there has been a standard set of tools. When it comes time to upgrade (e.g. VS2008 -> VS 2010), the whole team upgrades at the same time.


Project files should be in the repo -- unless you are automatically generating your project files with something like CMake, in which case you'd store your cmake project files instead of your generated project files.
[/quote]
What if the team consists of hobbyists? Some might not be able to afford the agreed upon IDE for example. I'm trying to determine how difficult it will be to have team members working on code in different IDEs.

Personally, I always use visual studio, which is free.

If you can't agree on a common one, then you can use a tool like CMake to automatically generate project files for several different IDEs.

This topic is closed to new replies.

Advertisement