Github has actually been working on a git extension for large data files. They support it on their system, as well as on Gitlab. I don't know about whether Bitbucket supports it though.

You can find the git large file support extension here: https://github.com/github/git-lfs

I'm not 100% convinced to the benefit of this. Its not like a diff or a merge can be done effectively between large binary files (I know perforce can do it between images but its rarely useful). Our artists often put the raw data (i.e photoshop sources) on a versioned rsync server instead. Only the output assets (i.e png files) and code should really be on a version control.

rsync is faster and more scalable than any version control can be I suppose.

Assembla has free Perforce hosting (max 1 GB disk space) which is what I use for my personal project.



https://www.assembla.com/

Thank you! I've used Assembla repos in the past, so I'm familiar with using their services already.

Have any of those complaining about subversion's branch/merge handling actually tried it with a version less than about 5 years old? Since SVN started noting branch and merge information in properties it has become much, much better at handling them. Haven't had any serious problems in a long time.

I think 2013 was the last time I used subversion on a large project. Pretty much every collaborative project I've worked on since has used Mercurial (mostly because GIT often pushes me off the fence when I'm considering joining a project).

That leaves Mercurial or Peforce for me?

I've been working on projects for over over a decade and hadn't heard of Perforce. I could just be out of the loop, but I imagine you'll probably have an easier time finding other developers already familiar with using Mercurial. That's not a good reason to choose an inferior product or a product that fits your needs poorly, but if all else looks equal, it's something to consider.

That leaves Mercurial or Peforce for me?

I've been working on projects for over over a decade and hadn't heard of Perforce. I could just be out of the loop, but I imagine you'll probably have an easier time finding other developers already familiar with using Mercurial. That's not a good reason to choose an inferior product or a product that fits your needs poorly, but if all else looks equal, it's something to consider.

??? Perforce has been a standard in pro development, especially games, longer than Mercurial has existed. As far as I know, the vast majority of studios are still using it today.

That leaves Mercurial or Peforce for me?

I've been working on projects for over over a decade and hadn't heard of Perforce. I could just be out of the loop, but I imagine you'll probably have an easier time finding other developers already familiar with using Mercurial. That's not a good reason to choose an inferior product or a product that fits your needs poorly, but if all else looks equal, it's something to consider.

??? Perforce has been a standard in pro development, especially games, longer than Mercurial has existed. As far as I know, the vast majority of studios are still using it today.

Never been a "pro" developer. Probably why I never heard of it.

No good UI other than SourceTree

If you like TortoiseHg, then TortoiseGit would do equally well with Git. I do not like SourceTree much, but that is just my personal preference. Using TortoiseGit I rarely find the need to resort to the CLI on my daily activities.

Regarding speed, I find SSH much slower than HTTPS. For instance, cloning one of the repositories from GitHub takes about 20 minutes over HTTPS, but more than 2 hours over SSH. That is on a very fast broadband Internet connection.

My games are going to be art asset heavy, almost from the start, (the small games which I have made already are) so the data demands will be stacked thru the ceiling soon enough. From this thread, it seems that GIT is out. Subversion is out.

That leaves Mercurial or Peforce for me?

Yeah Git it total shit for large data files. The only thing that Git does really well is branching. But other than that it was always a nightmare. For one thing it is extremely easy to get it into some bad state, where even "Git experts" have trouble figuring out what's going on. I've never seen this happen with Perforce, ever.

I'm telling you just go with Perforce and call it a day, although SVN would probably work out ok for you as well. But since Perforce is free I dont see why you would not choose it.

Edit: Actually i can see not going with Perforce if having a free cloud hosting service is important to you. Assembla is free up to 1 GB which wont work for you if you have huge data.

Okay,

Here are a few things for me to consider about how my situation influences my decision:

I have plenty of external hard drive storage for art assets. (about 1TB) Only my later beta versions and RC version will need the full art set. I can use a few placeholders until that time.

My PC could be used as a server part time (It's a laptop so my connection to the internet will be limited)

I like to pull from recent history

Branching will be simple

OpenGL is the API (probably not a factor in version control)

I am window UI happy but don't mind using some CLI

Questions:

1) How practical is it to use two brands of version control systems? ( I know that Perforce and Git are used by some dev companies ) Which one would I use for asset branches and the other for mostly coding? ( I tend to use placeholders for assets until later, which allows me more independence of assets and coding )

2) Which VC is most friendly to using my PC as a server? (Connected to the internet part time)

3) Everything must be no cost for several months, including server and storage. Which VC is out (no go) as far as this issue?

4) Any comments on compartmentalizing teams which VC? ( I would like artists to usually have no access to low coding, for example - favorite VC for this?)

1) How practical is it to use two brands of version control systems? ( I know that Perforce and Git are used by some dev companies ) Which one would I use for asset branches and the other for mostly coding? ( I tend to use placeholders for assets until later, which allows me more independence of assets and coding )
2) Which VC is most friendly to using my PC as a server? (Connected to the internet part time)
3) Everything must be no cost for several months, including server and storage. Which VC is out (no go) as far as this issue?
4) Any comments on compartmentalizing teams which VC? ( I would like artists to usually have no access to low coding, for example - favorite VC for this?)

1) It's annoying, but usable. The last big games company that I worked for used GIT for code and SVN for assets and it was entirely workable.

2) They'll all cope with that. You only need internet access to your 'server' if you want people outside your house to be able to access it. Usually you just set your PC to run a server program on startup, or have it configured as a service that runs automatically.

Personally I love Git's flexibility for this - you don't even need a server process, and instead, you can just use a shared network folder as a super-simple "server" :lol: I also like that you can use a sneakernet instead of the internet -- e.g. I can pull the latest version of the code from my work PC onto my laptop, go home, and then push those changes from my laptop onto my home PC and continue working (then do the reverse the next day to get my commits back to the office).

3) If you're self hosting, they're all free.

4) Perforce is probably the best here.

Out of the box, SVN lets you do some basic authorization and path-based restrictions.

Out of the box, Git doesn't even support users/passwords, but is designed to be used alongside other systems that add those capabilities.

1) Perforce can easily be configured to work as a Git server. You need to set it up so a clientspec can view whatever part of the file tree is it interested in. Once that is done, people can pull it down with P4V and similar tools, and they can also pull it down using git.

2) Each of the systems can do it. Git is more lightweight on your system than Perforce, but if you shut it down when you aren't using it, neither will be that bad.

3) Since you're not over Perforce's 20/20 limit, they're both no cost.

4) Perforce is much better at this. All the files get versioned together, but different people can isolate what sections they want to work with at any time. Programmers can view the code built assets, and any daily builds that may get checked in. Artists can see the source art, built assets, and the same daily builds if you are checking that in. Designers can store design documents and view the assets and builds. It is difficult to do piecemeal downloads in Git, but with perforce you open the configuration and list the path with a minus in front of it to exclude it.

Okay, cool

Just a couple more questions:

What is the technical term for when the developer decides that a version has had enough and moves all the teams to the next version? (be it alpha, beta, RC, or published versions or "subversions" ) Can I assume that this should usually be determined by coding needs? I was wondering if all the VC have a standard or is there always some degree of flexibility on development philosophy here with regard to pushing to the next version. I am assuming that all the VC let the teammates know that they are working on the next version automatically.

Does VC provide organization wide messaging, for example - a notification of some kind? ... or is that left to the developer to mass email them? Are any of the VC poor at communication?