Hi! My name is Nuno Afonso, and I'm currently the solo developer for Ark. I've been in the games industry for 16 years, working on games like Shadow Warrior 3, Cyberpunk 2077, Thronebreaker and Gwent, among other smaller projects you probably haven't heard about.
It was my frustration with the current state of the art in version control, combined with having to use this kind of software for the rest of my life, that pushed me to start this project.
I'd like to thank everyone that has supported this project, and I hope you'll find it interesting too!
Ark is still not 1.0, and it is a quite complex project with a lot of moving parts, so I strongly encourage you to please backup your projects often, specially when getting into more complex scenarios like branching / merging and when upgrading to newer versions.
When using it with an important project, I'd recommend to use it for a while in parallel with your current VCS before making a complete switch.
Whenever you get latest and there are files that you've locally changed, you'll have a conflict. To resolve a conflict you need to add a diff/merge application, which you can setup on File->Preferences.
At the moment there's support for WinMerge and P4Merge, but you have fields to define how arguments should be passed for any other application.
All information regarding licenses is available in the Pricing page.
Since 0.6.0 Ark ships with a Linux binary with Server and CLI support, and since 0.8.0 Ark ships with MacOS with Server, CLI and GUI support (i.e. feature parity with Windows version).
A distributed VCS adds a layer of complexity that on a day-to-day usage in game development - and perhaps in every other industry - doesn't solve any actual problems.
One of the benefits that will come from this is having a sequential number for changelists, making it easier and more intuitive to work with than with hashes, but it also opens the door to many other features.
This is a matter of development philosophy. Some people claim that branching for everything is the best way for development, but some of us disagree.
If you want to check out more about this subject, check Jason Gregory from Naughty Dog talking about it at HandMadeCon 2016.
It may sound counter-intuitive, but when following this approach development is faster and the project is globally more stable (specifically the complicated obscure bugs).
Following a trunk-based approach doesn't mean that you don't have branches. It means that branches tend to be created more towards stability, e.g.
trunk____________________________________________________________
\
\
staging_1.3_____
\
\
live_1.3__________________
\ \
\ \
hotfix_1.3.1 hotfix_1.3.2
So in the case above, you branch from trunk because you want to stabilize for release 1.3. Then eventually that version is released (live branch) and is patched twice (hotfix branches).
In the meantime fixes done on these branches get copied over to trunk, the process for that depends on the studio, but imo the version that works best is that when you fix something, you immediately merge it back to trunk yourself.
This doesn't mean that you can't do feature branches for example, but specially when working with non-coders it's much better to minimize branch swapping and use functionalities like shelves.
Having "Somefile.txt" be different from "SOmefile.txt" is just adding problems without really solving any important one.
When case sensitive is used, it happens that some developers have different cases in their folders and files. This generates a mess, with multiple versions in the server, and some users have one while others have another.
So if case-sensitive is important to you, Ark is not the right VCS choice.
Ark is being built with Jai programming language. At this point it uses GLFW for window management and Dear ImGui for the GUI.