Somewhat off topic, but I'd love to see something more git-like that works for large repositories. I work on video games and our repos are several TB. It's not practical to use git in those situations and Perforce feels too clunky to me.
I haven't tried it, but I've looked at it. I think it adds too much complexity. Who decides which files go on the annex and which don't? Doesn't seem like an automated great solution for a scale-able team.
I'm looking for something more like CVS/Perforce where you can check anything in, but then with a more Git feeling interface. What I'd really like to do is to look at Git feature by feature and build the closest thing possible that does not include cloning the entire history locally under normal use. I know that is the fundamental paradigm of Git, but it seems that something closer to a hybrid of Git and Perforce could be created. Not sure exactly what it would look like. It's just jarring to jump from Perforce/CVS to Git and I don't think that's completely due to the local repository model. It's how branching works, it's how merging works, etc.
> I haven't tried it, but I've looked at it. I think it adds too much complexity. Who decides which files go on the annex and which don't? Doesn't seem like an automated great solution for a scale-able team.
I would put all binary files into git annex (as determined by `file`). This can be done by a commit hook automatically. With another hook that makes sure that `git annex pull` is run when the user checks out code, you'd have a solution that was close enough to automatic for most use cases.
(You'd have to help your users with weird situations from time to time, but that's true of git anyway.)
If I was still doing games, I would be tempted to write to have a hybrid Perforce/git setup where code and text files are in Git and media is in Perforce. It would make atomic commits much harder, but would give you the lightweight user experience (branches, etc.) of Git for code and Perforce's solid performance (and no local history!) for giant assets.
We've got an answer for that but fair warning it's commercial, not free.
tl;dr: all the data sits in one or more binary server[s] and is fetched on demand when you ask for the file. We distinguish between text and binary so you can clone a tree and have all the text checked out and none of the binaries; you set up your build system to check those out as needed.
