Comments on: Some Code Organization Patterns First to say I don't work in games but in very similar software (flight simulation). We always check in all external dependencies (SDKs and libraries) in source form, and setup a script to build all dependencies. We have another script that sets up all paths to the correct places. So when someone checks out a clean version from svn you just have to run the script to build dependencies and start coding, no need to worry about which version of which library are we using right now. This way, when a bug in a previously released version to a customer you can just use the tagged version of the code and fix it, without the need to include all modifications and new features (and possible bugs) from trunk version. First to say I don’t work in games but in very similar software (flight simulation).

We always check in all external dependencies (SDKs and libraries) in source form, and setup a script to build all dependencies. We have another script that sets up all paths to the correct places. So when someone checks out a clean version from svn you just have to run the script to build dependencies and start coding, no need to worry about which version of which library are we using right now.

This way, when a bug in a previously released version to a customer you can just use the tagged version of the code and fix it, without the need to include all modifications and new features (and possible bugs) from trunk version.

]]>
By: Jeff Ward/2011/06/11/some-code-organization-patterns/#comment-5644 Jeff Ward Tue, 14 Jun 2011 18:27:47 +0000 I'm with Ian. Especially when working on multiple projects at once, which are on different SDKs, it's a pain to try to remember to switch SDKs manually. Disk space shouldn't be an issue in this day and age. Our main issue with this is sync times, but everyone has scheduled tasks that do their syncs overnight, right? ;) I’m with Ian. Especially when working on multiple projects at once, which are on different SDKs, it’s a pain to try to remember to switch SDKs manually. Disk space shouldn’t be an issue in this day and age. Our main issue with this is sync times, but everyone has scheduled tasks that do their syncs overnight, right? ;)

]]>
By: Julien Koenen/2011/06/11/some-code-organization-patterns/#comment-5517 Julien Koenen Sat, 11 Jun 2011 10:47:44 +0000 I've found two main benefits to including SDKs directly in source control: 1) Zero-thought distribution of new SDKs. It's easy to say "if you don't upgrade it's your own fault", but when you've got 10+ build machines and 20+ developers working over 3 or more platforms it saves everyone a lot of time if things just work. 2) You always have the right version of the SDK for a given copy of your source. It's not uncommon for new versions of an SDK to have breaking changes that require you to change your source. Keeping the SDK alongside your source ensures that if you have to sync to a previous revision of your codebase the SDK will automatically sync up with it. This also allows you to have two copies of your codebase (perhaps a development branch with the latest SDK and a locked down demo branch with an earlier SDK) with different SDK versions. I’ve found two main benefits to including SDKs directly in source control:

1) Zero-thought distribution of new SDKs. It’s easy to say “if you don’t upgrade it’s your own fault”, but when you’ve got 10+ build machines and 20+ developers working over 3 or more platforms it saves everyone a lot of time if things just work.
2) You always have the right version of the SDK for a given copy of your source. It’s not uncommon for new versions of an SDK to have breaking changes that require you to change your source. Keeping the SDK alongside your source ensures that if you have to sync to a previous revision of your codebase the SDK will automatically sync up with it. This also allows you to have two copies of your codebase (perhaps a development branch with the latest SDK and a locked down demo branch with an earlier SDK) with different SDK versions.

]]>
By: Ryan/2011/06/11/some-code-organization-patterns/#comment-5495 Ryan Sat, 11 Jun 2011 03:37:55 +0000 Hey Geoff, I agree with all your points but this one: "Install large 3rd party SDKs directly onto workstations". While your argument makes sense, from experience, its always a pain in the butt to have a new 3rd party SDK installed on every single workstation. You have to email the whole team to make sure they update, some wont do it, and are surprised when the code doesn't work, you need to also update the build machine, its a tedious process. I would say that the best option that I've seen so far is to have everyone use linux, and just point to the aliased folder on a server (I don't know if you can do that with windows). This way, you can quickly replace the alias to the new SDK and its transparent for everyone. No install, no source control. Unfortunately, its not viable today where most of our tools run under windows, and in that case, having those SDK in your source control, the distribution is still almost automatic. Eric Hey Geoff,

I agree with all your points but this one: “Install large 3rd party SDKs directly onto workstations”. While your argument makes sense, from experience, its always a pain in the butt to have a new 3rd party SDK installed on every single workstation. You have to email the whole team to make sure they update, some wont do it, and are surprised when the code doesn’t work, you need to also update the build machine, its a tedious process.

I would say that the best option that I’ve seen so far is to have everyone use linux, and just point to the aliased folder on a server (I don’t know if you can do that with windows). This way, you can quickly replace the alias to the new SDK and its transparent for everyone. No install, no source control. Unfortunately, its not viable today where most of our tools run under windows, and in that case, having those SDK in your source control, the distribution is still almost automatic.

Eric

]]>
By: The Toolsmiths » Some Code Organization Patterns/2011/06/11/some-code-organization-patterns/#comment-5491 The Toolsmiths » Some Code Organization Patterns Sat, 11 Jun 2011 02:03:49 +0000