Which version control are you using in your project ? Question to Indie developers!

Hi all Indie developers!
I reached the point , where i own a server grade hardware and definitely wish to have to run my own local onsite git (with LFS support) repository server.
I came prepared here, so basically i need good (opensource) Git server which can be configured easily and can be accessible from internet, (i do own a domain name and it works already for smaller projects).
The Git server should accept large files, (i know that i should ignore assets , library and other directories from my unity project)
My server came with preinstalled win7 ultimate os, i can install additional storage and run windows server, but i already put some investment to it and i am not big enterprise.
I do not plan to operate this server on 24/7 base, but rather on and off when i need to deploy i run it and when i dont need it stays off.
I know Unity as cloud services is great and other git providers are great too, but i wish to have my data safe and close.
If for some reason's my hardware would not be enough, then i just prefer to run git server inside Linux docker image, but then for persistence i would depend on cloud providers or i can setup the storage volume on site.
Anyone with experience with running own hosted version control please comment.

 

The company I work for uses Gitlab. It works perfectly fine for hosting our Unity projects.

 

Subversion with a Dreamhost repository.

Edit: Since someone mentioned context below I'll mention that our group has thirteen people. Only two of us were familiar with Subversion when we started but we were able to step the others through using it in a couple of hours with occasional help from time to time beyond that.

 

What @Ryiah said. If I were rolling my own solution, it would be SVN, not Git. SVN handles big binary files much-much better than Git, easier to use, basically more suited for game development in general.
I would probably set up an SVN server and back it up into a remote repo or just back it up into the cloud on any way.

 

Self hosted CollabNet Subversion Edge with Active Directory authentication. Not an indie developer, tho. We do many projects in parallel for different customers and need to be able to set up different levels of access privileges in our repos. Also, binary files galore as source art files go into the repo as well.

 

I like the Git interface, both for general use and ease of branching. That said, it isn't great with large binaries... there is LFS, but I haven't tried it. Professionally both the current and last studio I worked at use Perforce. It is has several advantages for large team and projects, but isn't cheap. The interface isn't awesome, and like about every VCS out there, uses the same terms to mean different things. (grr). At Disney, prior to perforce, we used a dual system. Code and main project delivery assets and branches were all in GIT, and all source art was in SVN. At the end of the day, I have come to prefer perforce. Locking is nice and it is very stable, even if a bit awkward to use at times.

 

Thanks to all responses!
I looked up how to install a svn server, it looks way easier then trying to configure a git server.
Funny thing: one guy actually told me that i need to learn how to install microsoft IIS server , so that i can run git server in it and i was like No, No, No
Easy to install comes with another "downside" a svn is old technology , which use centralized distribution model , even devs of svn make point here.
For me to use a svn make sense and i need pretty quickly to set up a "small" version control server, so that later if something get corrupted i be able to recover back from repo. This is my backup plan.

Using perforce its definetly overkill in my case, but its interesting to hear that some companies use it.
If my project grows and i would have additional participants , then i probably will use the cloud Unity services, it makes a lot of sense and i dont get myself in the situation of the weak link , because then if something goes wrong on my side it would effect others workflow.
So in that case it is actually make sense to deploy the sourcecode to Unity cloud service.
Then for team members it would be easy to share the contributed work between each other.

Its very interesting observation, but i try to do the best of it, so anyone who is in my situation here you go you have choices, but you should consider following: think and plan for grow and structure your project so that you wouldnt be stuck at some point of time!
Wish me luck, i hope that i pretty quickly would be able to setup a SVN server and push the code to it.

 

Azure DevOps with git, git LFS for large files. If I were rolling my own, I'd probably use git and git LFS as well.

 

In every company I have worked at other than 1 we used git + git lfs. I have never had issues with large binary files etc, but thats because you are meant to use lfs if you want to use git with projects like unity projects.

So if no lfs, go with SVN, otherwise git + lfs is just as good as SVN but you get differences in what you can and cant do. I prefer git but if your comparing SVN to git with lfs, its basically personal preference at that point as they are both ample for the task.

 

You don't want the newest version control software on the market. You want one that has been extensively tested because it will be responsible for all of your files. Furthermore while Git may be newer like others have said it's not designed to work with large files. That requires setting up git lfs which is developed by a completely different team. Two apps versus one.

 

I use SVN, on a home brew linux box. I have dynamic DNS already pointing to my home IP for reasons of running a game test server, which also works nicely with the SVN server allowing me to access it anywhere at basically no cost for my version control with no project size limits.

 

I use github for code and SVN (self-hosted) for art and assets. "Splitting up the tri-force", if you will.

I moved on from Perforce and onto github. It took time, but I feel like the migration wasn't really painful at all. I was running Perforce from my home server, but I decided to store on a hosted repository for security and reliability reasons. The change from centralized to distributed version control was a bit jarring, but being a solo dev on a laptop that may sometimes not have internet access when developing, git makes me feel a lot more productive than Perforce. I realized the only reason I was holding on to Perforce was because of my experience with it for several years at my former job, five years ago. It was time to move on. No regrets.

 

People are conflating what they know with what is best. What you know does matter but what's best might be different if you factor in longer term after going through the learning curve.

Hobby vs commercial and team size have a significant impact here and you can't not factor that in. Someone saying I use X and it works great without that context means next to nothing.

Perforce isn't overkill but it has the steepest learning curve overall. Not just it's use but you have no what I could call good cloud options for it, so you will likely host it yourself. It does have I think the highest potential upside outside of hobby/solo projects.

Git is just so good at managing code and github flow makes it even better. But is it worth having two VCS's. Maybe maybe not.

The one constant is git is not good at managing a lot of binary stuff. And distributed VCS for managing binary files can easily kill productivity. This is an area where it gets progressively worse with scale and will at some point become untenable.

 

He asked what we use, not what's best.

(addendum to my original comment - we don't make games so while we use Git, we don't have to deal with LFS)

 

Good point about context. I've added it to my first post.

 

I'm currently using Collab
I should point out that I'm currently working on a solo project and when working on a team using Collab it was a nightmare, but as a solo project it serves as a good back-up facility.

Previously used Subversion with Assembla for team projects (mobile) which worked well but never used since their price restructure.

 

Definitely. In addition to mentioning that I'm working on a solo project, I should also mention another reason for splitting the code and data repositories. Writing code and authoring data typically operate on two different cadences.

I find myself programming and checking in far more frequently and with a larger number of file changes than I do editing large binary files for art and audio assets, etc. The repo for my code is significantly less than half of the data repo, and as more content is created, that ratio becomes far smaller.

Keeping these separate means that they can be backed up separately. It also encourages me to separate my content from the program for preparing the overall architecture for, say, future mod support, and promotes building the game as an "engine" to plug data into.

I could have also created two separate repositories using the same source control, but I chose the best source control for the type of data, as discussed above. There's always been discussions about the "iffyness" of git LFS, and SVN's battle-tested large binary file storage. But, I like the fast-and-loose-yet-safe feeling of git, with branches and distributed/offline checkins. Perforce was always on the safest side, but it felt very restrictive and infuriating to deal with at times.

 

I use hosted PlasticSCM. They have on-premise options as well.

 

As a lone developer, I tried Mercurial a long time ago, but ran into repository limits on Bitbucket, back when they offered Mercurial hosting.

Then I tried Plastic SCM locally, then hosted on a free tier Azure Windows server, then eventually hosted on their cloud service when it was in beta. It was great, but I couldn't justify paying for the cloud version when it came out of beta when other solutions were free.

So I moved to Git using free unlimited Azure DevOps hosting when it was called Visual Studio Team Services. It worked fine but it was a little slow, as I wasn't using GitLFS at the time.

Then I moved to Unity's Collaborate for a while, but had some problems with it losing some of my changes when re-downloading my project.

So now I think I'm about to finally settle on using Plastic SCM again with either another computer as a server, or pay for their cloud hosted version. And then maybe I can actually get some development done instead of playing around with version control.

 

I use Git with Azure DevOps for a pretty large project, haven't done anything special for large binary file handling, and everything is groovy. I believe all new repos there come with LFS by default now.

I've looked into SVN (which I used to use back in the day) for it's claimed superior handling of large binary files, and all I can see about benefits there is the lack of a local copy of the repo data means less duplication of those files? I think that just happens to be a non-issue for our project, at least for now. Are there any other benefits there I'm not aware of?

I used to run a local Git host at one of my old offices. Setup was trivially easy because we already had a file share set up and didn't need anything extra on top of that. We just created "bare" repos in there, pointed everyone's local clients at those, and off we went. Of course something that simple won't meet everyone's needs.

 

I want to drop here some short and quick news, thanks to all the people who recommended the SVN!
It was less painful then i imagined.
If i compare the set up of IIS and running there git, svn in my opinion wins automatically.
In my case, to set up a svn server and client was really easy.

Most work was on windows security side, the actual setup of svn server with client was actually pretty simple and obvious stuff!!!

​

Its kind of strange going back to the roots (I recall those days when i as trainee did pushed the code to svn), but as i mentioned this is pretty good solution, when my project grows and i will collaborate with other team members only then i would consider to move the stuff outside of my box
Anyway once again huge thanks to all of the people who recommended to use a svn !

For the git friends i was able to set up the git for my project too (I already used one git server solution for local repo) , but it's not so stable as svn, because for java application which implements git per default there not enough memory, so i just reserved 4Gb memory and set max allowed size per file 4gb and finally it did worked.

Conclusion: setting up a version control feels like a lot of work , but in the end it gives a lot of options.

 

Github for hosting, and SmartGit for my UI.

Absolutely love SmartGit!

 

What do you guys think about the "GitKraken" - Client?

 

Its pretty looking, but I found at the time I used it it was a little buggy and did not offer everything I wanted for free

You have to pay to use it with private repositories which immediately means its worse than free competitors.

 

I use GitKraken (free) on a private repo. I do like the interface, and it definitely feels like a crutch, because I still need to use the command line to push to github. I think it's worth the $29 a year, although I haven't pulled the trigger yet, since I'm comfortable with using command line.

 

The problem with all cloud services, they can experience some tech issues or even be not accessible, due the internet outage. Look into GitKraken TOS, i personally can recommend to have a hybrid solution, local repo with cloud, this is definitely better, if one of the repos goes down then you have a backup.

 

I totally get where you're coming from with having a local repo, as I've had my projects on a local Perforce repo well over five years prior to my switch to github. In fact, I used to run my server from a USB stick on my local machine. That way I could move the server with me whenever I want. With a distributed source control system, you don't succumb to the problems of "internet outages". You can still submit changes to your source control locally, and when the service issues are resolved, you can push your changes to the cloud. To me, that feels like the best of both worlds.

Having a locally run VCS has introduced its problems over the years. Occasionally, my local machine's network card would lose signal, or maybe it was the router, or the cable service. Who knows. What I do know is that if I was away trying to check out my server remotely, and I get an error connecting, I wasn't there to fix it, so I was SOL until I got back. It could even be a reason as simple as Microsoft deciding to do a forced Windows Update that puts you back at the login screen. Same deal. SOL. But github would definitely have people fixing their S*** without you having to spend time to do so.

With that all said, I still keep my art on a local SVN server, so some would technically consider my solution more Frankenstein's monster than hybrid, but I like how I have it set up.

GitKraken is just a frontend. It's just a pretty wrapper for github commands, so I could use git without GitKraken if I absolutely need to, but GitKraken makes some things more convenient. Such is the case if you have a private repo using the free version of GitKraken, as mentioned above. You can actually access your private repo, but you cannot push/pull to the remote service. So, if you plan to stay local, you certainly can.

As far as backups are concerned, that's a different topic altogether. I usually backup both my git and SVN (and previously Perforce) every other week or month, depending on my activity. Each VCS has its own way of compressing your repository for backup, such that it's easy to restore whenever that time comes.

EDIT:
grammar

 

Amazon CodeCommit is really nice if you want to "store" a single pet project that ran out of space on something like (official remote) GitLab. Also, no need for LFS. So less error prone setup;
(50GB for free, after that its per GB)

In case if its multiple projects - GitLab with local server is probably best in terms of git.
I've used SVN in the past, and yeah, I don't like how it handles branches.

 

In my case i have pretty good hardware server grade A+++, its a dedicated machine .
I believe in options, cloud is cool and i use it too, but as said early it depends on the case.
Having local repo definitely make you feel safe, because you have direct control over it, cloud can be used for fast sharing your code between team members and its inefficient to run local version control like 24/7 (Basicly its like highway and simple village roads , both are important and both make sense for data transportation)

 

We're running git on our own server. It's just a Ubuntu box in a corner of our office. No LFS - we haven't really noticed any slowdowns, and we're not size-limited. It doesn't seem to be an actual issue. Assets folder size is currently 23 gb.

 

We use azure devops and git lfs.

Works really well, only limit is 1 gig per commit.

Our game is 30 gigs 85 included library (which we don't version offcourse) also game is a few gigs larger than 30 gigs when all lightmaps are baked

 

SourceTree in front. BitBucket at the back. Git to do the bits in between.

It's just the first combination that happened to work out nicely for my small scale projects. I'm very much of the "if it's not broke, don't fix it" school of thought. So it's likely I won't change until I start having problems.

 

Interesting observation about svn: when i import my repo to the svn server i forgot to checkout and now i have two separate directories one is original which i use for git and another one is backup for svn commits only, so when i did commit to git and then i copy all files from original directory to the backup and then commit the changes to svn. I can force addition of new changes to svn , but i decided to manually add the new version of files.
In Windows TortoiseSVN even show which folder are not added and which files need to be merge.

 

Yes. That said if you kept a remote copy and were simply using the USB for the day with the goal of transferring everything to the remote once the day had ended it wouldn't be that bad since at most you would only lose a day of work.

 

TortoiseSVN is half of what makes SVN so great - it works like a dream in windows!
On Mac there are various free/paid apps, but nothing like TortoiseSVN!

 

Running a server from a USB stick definitely wouldn't work for larger repos, but as it is, my SVN server data is about 1 GB, over 5 years, so I'm certainly not dealing with extremely large data (at least not yet) and writing that data as frequently as my code repo. The SVN "Relocate" function gave me the freedom of mobility to run it locally or self-hosted at home, especially during a time when my Internet wasn't as reliable.

Regarding how easy it can be to lose the USB stick while mobile, I was in a different state of mind back then, where I had to keep my projects "on my person" at all times, with the same importance as my wallet/keys/cell phone. I couldn't tell you if it was better or worse, because I've probably lost my personal things about as many times as I have lost data, which is "rare, but it happens sometimes". I'd weigh out the pros and cons of keeping data remotely or locally, the house burning down or broken into, hard drive failure, the server machine getting infected or hacked, me being assaulted or injured or dead. Of course, all of which are very extreme, with the most probable case being that I just lose the stick. In that case, while I'd still have my workspace changes on the laptop, I definitely would have lost all change history back to last backup.

Nowadays, I still run the server on the same USB stick on my box at home, and haven't moved the stick around much. I still only have about 95% uptime, since I'm running it on Windows, and the aforementioned forced Windows Update is still an occasional problem.

Also, I thought I was going to periodically copy and swap out USB sticks, and just store the old one as a "last backup", but this hasn't been the case, as I make backups on the box, so there really is no need to consider the USB stick for backup.

I just realized that the absolute initial reason I went USB stick was because I used to run an external hard drive for both my Perforce and SVN server. The external drive was bulky, so moving the servers to a USB stick made sense from this angle.

 

I'm not sure why you go through all that trouble. For a light repo like 1GB, you probably can get an git solution for free and not worry about losing you USB drive.

 

I'm not sure if you read my entire post

 

Interesting, Unity just acquired Codice, the makers of PlasticSCM. Very interesting.

https://blogs.unity3d.com/2020/08/1...ng-version-control-to-real-time-3d-workflows/

 

I just got the email from Plastic.

I have mixed feelings about this. I'm glad for the plastic team, they totally deserve the promotion and recognition for their excellent work. On the other end, unity is already in the habit of leaving things unfinished and neglected.

So I hope plastic will remain independent strategically wise. I literally signed up with them to get away from collaborate because of unity's terrible management and would hate to see plastic go down the same road.

 

Queue three months down the line; "well, we've tried really hard, but we want users to have a unified experience and not silo them into different vcs', so we're dropping support for Plastic and focusing on Collaborate. It might be the worst version control system ever, but at least it's got a UI that matches our vision!"

 

Smart move buying plastic SCM as all the big unity games out there tend to use it. That said, I now fully expect unity to destroy everything that made Plastic SCM good, based on their habbit of buying up stuff and leaving it an unfinished and unsupported desolate wasteland.

 

Update on this, I realized that Visual Studio already has good tools for git, including pushing to a remote git repo, and as I'm already used to the Visual Studio UI, so I decied to use that instead. GitKraken was nice while I was using it though. And I liked the play on words for "get crackin'". Anyway. Go Seattle?