Data files

[GoogleCodeExporter]

I think data files should be under version control too. It would make updating 
them much easier and allow easier user-compiled running of the game.

Currently it is kind of a hazzle as there are some data files in the repository 
but not all and not enough to start the game. So user needs to drop the data 
files into the source tree in which case they mix with the others and 
Mercurial's hg status and even hg diff become unusable due to large amount of 
untracked or changed files. An alternative for the user is to keep the data 
separate, but that then involves copying or linking the binary and changing 
directories etc, which becomes cumbersome for developers that do frequent 
compilations.

The data files seem to be about 126Mb in size, which is of course far, far more 
than the bare sources, but I think still quite small and manageable.

So my primary suggestion is to add everything to the repo.
Pros: Easy to maintain, no hazzle with untracked files etc.
Cons: Larger repo size

Other possibility (not my favourite, but better than current situation)  would 
be to add the bare minimum required to run the game (e.g. one track, one car).
Pros: Can still test the game easily, even though repo size is not increased 
too much
Cons: Other data files are hard to manage and update, data files in multiple 
locations

Third option would be create a separate repository for the data
Pros: The core source repository stays neat and clean
Cons: More hazzle managing and adding two repos (though less than downloading a 
Windows release and manualy picking data from there); not sure if google-code 
even supports this

Original issue reported on code.google.com by tapiovie...@gmail.com on 20 Mar 2011 at 10:00

[GoogleCodeExporter]

Already discussed that on mail with CryHam. We decided to make a second 
repository. Here's the link, although no content yet: 
http://code.google.com/p/vdrift-ogre/source/list?repo=data

Original comment by scrawl...@gmail.com on 20 Mar 2011 at 10:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, let me put here my point of view.
The code repo should be best for quick getting the latest version for build. It 
will grow
bigger because of commits and so. But if I'd put there data too it certainly 
would slow down. So let's keep it for code and materials, scripts and such 
things that can be edited from time to time (they are associated with source 
somehow, wrong material can crash on other code). hg gets the whole repo with 
history so I guess it would get slow soon with all data.

So I'm definitely not for 1st option (having data and source in 1 repo). I kind 
of like the 2nd option with minimal data, but the third is the best for me 
(separate repo's for code,data and tracks (or just for data ?)).

One thing is speed - we need fast pushes and pulls, hg doesn't have to check 
all textures and tracks and so, when pushing code (I can't imagine hg doing it 
fast).

Second thing is space - we have releases containing data, currently it is so:
 534 MB (13% of total quota)  = 4.8 MB Source + 530 MB Download.

And third - many people probably want to get the game (not 150MB only 60MB) to 
see how is it the gameplay and don't want to download much, unpack it (and know 
where), or certainly don't know how to use repo to get data (that for are full 
game releases with 5 tracks or so). Some of them could use more tracks if they 
like the game (but still don't want to use repo).

Downloads can be deleted. I don't know, but big data from repo cannot (am I 
right ?).
I'm also thinking that it would be good to put full releases and track packs in 
SourceForge, so we could have data repo and everything newest here. Is it the 
best option ? What do you think ?
And finally at some distant future it would be great if the game itself could 
download more tracks from repo (guys from VDrift are implementing this for 
svn). Thus I like the option of tracks being a 3rd repo.

Original comment by Cry...@gmail.com on 20 Mar 2011 at 11:40

[GoogleCodeExporter]

As discussed in IRC, there is now 3 repositories, all containing files. 
Compiling guide is also updated. Closing.

Original comment by tapiovie...@gmail.com on 20 Mar 2011 at 3:03

• Changed state: Done