Opinion on setting up SVN directories for a project

Hi guys, we're setting up an SVN server to host GOOF code, but will be including all src and dependencies and everything that is needed to compile GOOF.

The basic idea is that if you want you can go to SVN and checkout the whole thing and run it without needing to compile, since all the binaries are there already, but also all the source is there for GOOF and all dependencies (Ogre, OIS, Opcode, etc.) without needing to do any additional downloads.

This will basically be a place you can get GOOF binaries as well as GOOF source.

The other objective is that someone who already has set up Ogre, PLM2, and whatever else they want can just grab the GOOF src if they want to set it up themselves.

I want to set this up the way I'd be setting up my actual game development structure for my own game. In that case, I wouldn't want to be using Ogre's media folder, nor necessarily put my project under the samples directory.

Here's what I'm thinking:


Bin
Debug
Release
GOOF
(all projects post build event copy to Bin in root)
GOOFGameSystems
GOOFSoundGameSystem
GOOFOpcodeCollisionGameSystem
GOOFResourceBackgroundGroupGameSystem
GOOFAppFramework
GOOFCommon
GOOFCore
GOOFEd
GOOFEdSystem
GOOFEdPlugins
PagingLandscapeGOOFEdPlugin
GameObjectGOOFEdPlugin
GOOFExtension
Media
(different than the ogre\samples\media)
(contains GOOF shared media, objects, meshes, materials provided by GOOF)
(contains your projects assets as well)
(also has a copy of paginglandscape media)
OpenInputSystem
(full source for OIS 0.6)
(static linked - no need to post build copy)
Ogre
(full source for Ogre + PLM2)
(modify all projects to additionally post-build event copy to Bin in root)
Opcode
(full source for opcode 1.3.2)
(post build event copies to Bin in root)


What do you think?

In this case, ogre is set up as it is when you download the source and/or get it out of CVS, except the projects are modified to do an additional post build event to copy files to the Bin directory in root. Same with the rest of the projects.

Since this source is outside of Ogre's CVS for source control, what we'll do to keep SVN up to date for things like PLM2 etc. is integrate the latest changes from CVS into SVN. I don't expect we'll be doing this very often for Ogre code, but perhaps for PLM2.

Thoughts?

Two more options I'm considering:

1) Don't modify any of the post-build events for Ogre or PLM2, and have GOOF post build copy to the Samples\Common\Bin folders.

or

2) Don't modify any of the post-build events for Ogre or PLM2 and instead add a post build event in GOOF that copies all the relevant files from Samples\Common\Bin. This would mean every time that every time GOOF builds it copies 14 mbs of dlls from that directory (when in debug, less in release).

The reason I'm avoiding option 1 is because I don't necessarily want to have to run from the Samples\Common\Bin directory. I like to be able to isolate what media files are required by my game from the ones included with Ogre. I may also have a modified version of the plugins.cfg, resources.cfg, paginglandscape.cfg, etc. that doesn't match the ones in the Samples bin directory.

The other thing is that when you want to create a binary release you could just use the root Bin and Media folders and not have to worry about all the Ogre media. I suppose it wouldn't be hard to do that by creating a batch file that simply did that for you, copying only the folders you wanted from media though.

Modifying the Ogre projects is going to be painful every time I want to integrate Ogre HEAD into our SVN server, so I don't necessarily like that idea either.

I'm leaning towards option #2.

Another option that I really don't want to do is add the Samples bin directory to the system path. I'm not sure why I don't want to do it, it just feels wrong

Thoughts?

I do use 1) to release binary plsm2 and source. (simple dos cmd line automated batch, using Filezilla as ftp uploader, and 7zip as compressor)
Now it's a "click release".
Here is the batch that should gives you hints.

copy /Y "e:\lib\OgreSDK\bin\release\resources_plsm2.cfg" "e:\lib\OgreSDK\bin\release\resources.cfg"
copy /Y "e:\lib\OgreSDK\bin\release\plugins_plsm2cfg" "e:\lib\OgreSDK\bin\release\plugins.cfg"

"d:\Program Files\7-Zip\7z.exe" a -tzip -r OgreSDK_PLSM2_binary_demo.zip @binarylistfile.txt
"e:\tools\FileZilla\filezilla.exe" -u "e:\lib\OgreSDK\OgreSDK_PLSM2_binary_demo.zip" ftp://username:password@myftp.com -close

copy /Y "e:\lib\OgreSDK\bin\release\resources_orig.cfg" "e:\lib\OgreSDK\bin\release\resources.cfg"
copy /Y "e:\lib\OgreSDK\bin\release\plugins_orig.cfg" "e:\lib\OgreSDK\bin\release\plugins.cfg"


I should really make a NSIS distribution... but problem would be source release for Linux would make me maintain both NSIS and batch files...

I like to be able to isolate what media files are required by my game from the ones included with Ogre.
note the resources and plugin save, backup and restore around the distribution making. It uses a special resources and plugins that select minimal media required.


After some OgreOde distribution results, I'm thinking about simplifying a lot PLSM2 distribution, using same scheme, but proposing 3 projects files (*_CVS.vcproj, *_SRC.vcproj and *_SDK.vcproj) that uses each particular folder structure to handle each configuration, but wihtout all actual copy and paste "part".

XP from plsm2 is minimize at most installation step, if any.
(only real problem in plsm2 will be the datasrc.zip problem...)

Note : SVN keep in local and in distant copies of data. A SVN repository takes much more place than a CVS one. Be sure you'll have enough room for your plan.

Okay, I think I'll do the same. Thanks for the advice.

Maybe I am too anal, but I hate the layout:

GOOG\
GOOF*
GOOF*

You don't need all those extra GOOFs, you already in the GOOF subfolder. Why have them in a subdriectory if you are going to prefix them all?

EDIT: Don't forget to use svn:externals for any project you can. Hopefully Ogre will soon be in svn, so you can use svn:externals for it.

EDIT

Ah, you have a problem with naming convention of the actual folders. Point taken, but that's a matter of taste. They're in the GOOF namespace so I'm naming the folders as such.

I don't think any of the external dependencies I'm using in GOOF have SVN servers yet

hello Falagard
Is GOOF available as binaries somewhere(for windows)? did you manage to setup the SVN servers?

No binaries that are up to date. SVN was set up and then dismantled, and GOOF was put into ogreaddons CVS since then.

This sound like a pretty much good idea, that way you won't have to worry about Ogre breaking.

14 mb to copy each built is almost nothing, so there's no worry about it.

Have a folder that isolate all the DLL's is great because it's more WYSIWIG.

Great idea - the startup costs to goof are pretty off-putting at the moment. I was thinking of writing a wrapper or script, but the svn idea sounds great.

This is old info, look at the date of the original post. I'm not moving to SVN anymore, but will be setting up pre-compiled dependencies for VS 2003 and VS 2005 for those who don't want to have to try to compile the various dependencies and will host them off my own website. The setup for GOOF will end up as simple as downloading the dependencies and getting the source from CVS or a source release online.

One of the biggest problems is that I need to have a stable version of the PLM2 that I can tell users "go get PLM2 v1.15" or whatever and that it's the only supported version.

Maybe what you can do at this stage is to provide precompiled PLSM2 binaries (.dll & .lib) together with GOOF - VC8 .lib may satisfy majority of people here.

Edit: And not forgetting header files.

Not a bad idea to include PLM2 as a dependency.

Ouch, I didn't see the date that this post was first shown.