Just one caveat, Git is not that great in handling large binary files of which we have quite a few, since all our simulation assets are basically checked in together with the code into SVN. Yes storage is cheap, but wasting space with binary data which cannot be properly diffed just feels not nice. Apart from this when working on SSDs storage isn't that cheap anymore. Luckily the git large file storage extension was recently announced by github including a reference implementation of a storage server, so we decided to jump on this opportunity and try this out.
Setting up the LFS-reference server for a first test run was easy, our testing-infrastructure-guy churned out small script which takes over the configuraiton - which basically is setting a few environment variables - then starts the server. For the moment we just blatantly ignore any security issues. The server ran smoothly, so since we're already using Atlassian products we decided to install the trial version of stash as well
and got our developers to download SourceTree as a Git client. Especially our modelers and content-creators are not really keen on using Git from the command line so a nice UI will help getting them to accept the new tool.
Installation of the git-lfs client went smoothly as long as it can find the git-executable in your $PATH variable, if not the path can easily be supplied manually. Configuring lfs, registering stash as a remote repository and initially checking in our codebase and resources went well when done from the command line.
Tracking large files is very easy by supplying patterns similar to the ones in the .gitignore files
git lfs track "*.mp4"On every push to the stash-repositories the files would be checked in into the LFS and stash would only get a text-file containing a hash & file-size for the files stored on the LFS server.
Sourcetree did not find the LFS-Extension at first until we realised that we needed to switch from "embedded git" to system git. But there the troubles would not end, since the LFS server did not run on the same hostname and the user needed to enter two sets of credentials for a push and aparently sourcetree could not handle that additional dialog. After a bit off googling we could fix that by using
git config --local credential.helper storewe could enter the credentials once on the commandline and since they would not be asked again sourcetree could cope with this. What's not nice on this is that the credentials are stored in plain-text on the users machine. Here the winstore-helper for git comes in handy. This helper lets you use the windows credentials-system for storing the credentials and we considered that reasonably safe and on a plus side one can use the windows credentials settings to manage the credentials.
So basically we now have a running evaluation system with stash, the git-lfs server and users which can use the convenient UI of sourcetree to work with git. So where do we go next?
- First on we will try to get more experience with LFS and will try out if we can get rid of the credentials-workaround by putting the LFS-server on the same domain as stash.
- Then we will see if we can get stash to work with the LFS-extension
- And last but not least we will fiddle around with the development workflow to see what works and what not.