Jump to content
  • Advertisement
Sign in to follow this  
_Sigma

Source control - should trunk be buildable

This topic is 3743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a library of code which is dependent upon Boost, Cppunit and Intel's Threading Building Blocks. In my SVN repository should I have all the needed files from each library so the user can build it straight off the trunk, or is it better to just say "you need these 3 libs - I leave it up to you"?

Share this post


Link to post
Share on other sites
Advertisement
I'd say the latter because the user might have already installed them anyway (e.g., boost).

Share this post


Link to post
Share on other sites
I generally put everything required to build my projects in source control, such that building is a matter of "check out, click batch file, profit."

However, there are a few exceptions: I don't include binaries for the CRT, Win32, D3D, or Boost. Pretty much everything else is fair game, unless the license for that dependency or tool forbids distribution.

In your code I'd put Cppunit and the threading stuff into source control, if possible.

Quote:

I'd say the latter because the user might have already installed them anyway (e.g., boost).

This is actually part of the reason its good to include the dependency binaries with your repository. The user might have that dependency already -- more importantly, they might have a different version which is incompatible in some way, causing compiler or (worse) runtime errors.

Then they either file non-reproducible or difficult to track bugs against your project, or are forced to screw around installing a bunch of dependencies, or both. Developers are users too, and one should strive to make the user experience for one's projects as smooth as possible.

Share this post


Link to post
Share on other sites
I think the proper binary versions are important. And something should build out of the box. I think it should be the trunk, but some think that releases should be on a branch or a specific tag. In that case, the branch or tag should build out of the box, even if the trunk doesn't.

Share this post


Link to post
Share on other sites
In my opinion stuff like that does not belong into the source code repos.
I'd rather load a second archive (from an ftp e.g.) then downloading 100mb on every svn co.

Share this post


Link to post
Share on other sites
Quote:

In my opinion stuff like that does not belong into the source code repos.
I'd rather load a second archive (from an ftp e.g.) then downloading 100mb on every svn co.

What's the difference between downloading it once via FTP and downloading it once via SVN? You only need to refetch it from SVN if you delete it locally or if it is updated in the repository -- these happen to be the same conditions you'd need to re-download from your FTP site as well.

Sane version control systems don't download the entire repository every checkout/update/sync. They only download what has changed. I don't think bandwidth makes a valid argument here, it ends up being the same with either option.

Share this post


Link to post
Share on other sites
I am a firm believer that EVERYTHING required to build the app should be in source control. The compiler itself, libraries, headers, tools, and every other byte of stuff required for building the game. This even includes stuff like nant, the command line versions of visual c++, and the necessary contents of the DirectX sdk.

Disk space is cheap, and it is better to have all of those libraries around so everybody shares the same version.

It is too easy to have bugs caused by different libraries, one teammate with 1.7.2.2 and another with 1.7.2.3. Those non-bugs take a long time time to track down, and are a complete waste of valuable development time.

The cost of hunting down a single bug caused by developers on different versions of a library is far greater than the cost of installing a few extra gigabytes on the server.

I also completely agree with jpetrie on the philosophy: "check out, click batch file, profit."

I strongly feel that you should be able to take any freshly installed empty machine, install the version control software on it, enter a single command to download everything you need, and run a single batch file to produce the final game.

It may take a long time to build everything from scratch, but the fact that you can do it is important. When a new developer joins the project or a developer's machine fails and must be replaced, this detail can save many hours of headaches.

Share this post


Link to post
Share on other sites
I agree with frob and all other with such an opinion.

Additionnally, there may be situation where one wants to modify some library. Perhaps not with stable stuff like boost, etc. but it still happens one in a while.

Share this post


Link to post
Share on other sites
I should add that if you want to encourage other people to use and/or modify your project you should make things as easy for them as possible.

For example, I am less inclined to take a look at someones project on my own time if it takes me forever to configure the build.

Also remember that even if your trunk turns out to be huge, it won't matter that much because after the initial checkout the amount of data transferred will be nominal.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!