Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move binary assets out of git #32

Closed
bkloster opened this issue May 18, 2013 · 2 comments
Closed

Move binary assets out of git #32

bkloster opened this issue May 18, 2013 · 2 comments

Comments

@bkloster
Copy link
Contributor

Git doesn't handle binary files like zips, meshes and textures very well. They tend to bloat the repository, because git has to maintain a complete copy for each change that has been committed to the file. Besides, GitHub would like to keep each repository below 1 GB. If we continue putting binary files into the repository, we will quickly reach that.

There are a variety of options to keep binary files in one place and share them amongst developers and artists:

  • Dropbox
  • FTP server
  • Perforce (free for open source projects)

Both the FTP and Perforce server could be set up on the build server, once we have such a thing.

@bkloster
Copy link
Contributor Author

Perforce is out, as the free license is limited to 20 users. I have no idea how many people will eventually need access to the binary repository, but I'd rather not run into problems when our 21st contributor shows up.

I am in the process of setting up a Subversion repository for binary files. Subversion is not ideal, but it offers some advantages over FTP or git:

  1. It's versioned. If someone messes up a file, we can revert it.
  2. It supports locking a file, so only one person can change it until it is unlocked
  3. It supports checking out a subdirectory and only downloads the requested revision (git always clones the whole repository).

It comes with a few disadvantages, of course. For one, it's a little more complicated to build Thrive as developers will have to juggle both the code repository in git as well as the asset repository in SVN. Second, non-coders usually have a rather skeptic opinion of version control, so artists might be reluctant to adopt it.

@jjonj
Copy link
Contributor

jjonj commented Nov 18, 2013

developers will have to juggle both

I don't mind. I'm also familiar with SVN.

Second, non-coders usually have a rather skeptic opinion of version control

Don't know about that, But people who are unwilling to use it could just have someone else add it to the SVN. Files will be moved around between people on the forums often anyway.

@bkloster bkloster mentioned this issue Nov 20, 2013
@jjonj jjonj closed this as completed Nov 21, 2013
bkloster added a commit that referenced this issue Nov 22, 2013
Fixes #32

The res directory has been removed. The directories res/scripts and
res/ogre_cfg have been moved up into the root directory.

CMake now offers an option to set the asset directory and throws an
error if it doesn't exist or is empty.

Asset creators can now put their files in the "testing" subdirectory of
an installation to override any other resource files.

Move scripts up one directory

Remove binary assets from git

Add "testing" resource directory

The content of this directory overrides all other resource
directories.

Move res/ogre_cfg to ./ogre_cfg

Let's get rid of that res directory

Remove unused music file

Will be added to the asset repository later

Remove res directory

The Blender files have been moved to the asset repository

Fix SVN URL in CMake warning

Add username / password hint to CMake asset warning

Promote CMake asset warning to an error

In theory, users could build Thrive without assets, but it
wouldn't do them any good because there's no way they could
execute it.

Better README.md

Add simple explanation for Subversion art asset

Add dependency list for Linux developers

Attempt to fix links

Write out ftp link since GitHub seems to filter them
hhyyrylainen added a commit that referenced this issue May 4, 2021
…rn/websocket-extensions-0.1.4

Bump websocket-extensions from 0.1.3 to 0.1.4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants