I must protest!

I'm just a little annoyed by the business model Unity Tech has taken up in the last few years.

I've normally been a solo dev, so I haven't needed features like the Asset server or Unity team. I recently joined a Unity fan game project, and honestly I am very annoyed by the lack of alternatives to the asset server/team services.

I've read about these business moves but they've never impacted me too much and so I just ignored them.

3 seats for Unity Teams, with one being taken up by myself.Otherwise its using Git to hold the *entire* project, which grows by the GB with every commit!!

The real question is just how does Unity Technologies expect an indie dev to afford things like these features in the current market??? What about a fan game?

Really not cool. Very much considering switching to another engine.


Unity pro costs $1000 a year if I'm not mistaken, and honestly I am not a rich person by any means. That is like 1/4th the value of my vehicle, which was *not* easy to afford.

 

You are mistaken. If you are not rich, you can drop down to a plus or personal. Which makes things very affordable. You can't get much more affordable then free.

You are doing something wrong if you are growing a repo by GB with each commit. I suggest trying to solve that problem, rather then spending more money on services.

 

Indeed, I've been using Git with Unity for many years, and never had this issue. Right now I have a repo that's ~4.5gb (on the server) after more than 2 years of heavy development and being somewhat careless about what got checked in.

My first thought is that you're not properly ignoring stuff, and are pushing up new versions of your Library folder on every commit. That will waste oodles of space in your repo, and it'll waste a bunch of time every time you pull because every local machine will have to clean up and rebuild locally. Plus I hear it can cause errors.

Assuming you have one, can you post the contents of your .gitignore file?

I agree that Collab itself isn't particularly competitively priced. But, aside from that, the trend is actually towards their tools being cheaper. When my studio started using Unity we ended up buying Asset Server licenses because Unity didn't play well with 3rd party version control. Later they added text-based serialization, which meant we could use other version control systems and didn't have to buy those licenses any more.

 

The Asset Server was deprecated back in 2017.1 by the way.

If your commits are always that big, it won't be automatically resolved by using a Unity product or service either. If you don't want to pay a monthly cost for your version control, possibly due to its size, you can self host a Git or SVN repo. 8TB drives are around $200, so should be able to handle about 8,000 of those commits even if you're unable to figure out why your commits are unrealistically large. If you need more space you can just RAID 5 several of them together.

You shouldn't jump to the conclusion that indie development should equal free as in free beer development. If you need a service, you should expect a cost associated with that service.

 

The Unity Pro plan costs $125/month, which sums up to $1,500/year - that's about the price for the perpetual Unity Pro licence that existed before Unity Technologies decided to use a subscription-based pricing model (like every big player out there does nowadays).

For your Git issue: As @angrypenguin said, can you post the contents of your .gitignore file (if one exists)?

 

Totally agreed. However, in the particular case of version control there's Visual Studio Online, which offers "unlimited" Git repos for free for teams of up to 5 people.

There are also other options without fees. They all have limitations, so scout around for one that best suits whatever you're doing.

But remember that with Git every client has a copy of the full repository history. So any junk you put in there will be carried around forever. So I'd solve the issue, make a new repo, and copy (not push!) the contents over to that repo so you're not carrying around your early, huge commits for the remainder of the whole project.

 

Out of curiosity, is there a way to make a git repo drop early commits and diffs?

 

I'm not 100% sure, but I'm not aware of one, and the idea doesn't fit with my understanding of how git works.

Personally, when a project reaches a point where development has "stabilised" and we're no longer making large changes other than adding content, if the repo is large we'll just make a new one and copy the contents over. Losing the history of old commits is a downside to this, but it does mean that we're not carrying around a whole bunch of old assets we're no longer using. And we keep the old repo, so if we do need to refer to something old it's not lost, it's just a little more work to access.

This is one case where Perforce is nicer than git. The history is not stored by the client, and you only "map" parts of the project you need access to between the server and your local workspace, so no client needs to have any data that's not strictly relevant to what they're doing.

 

wont kill the old stuff from the remote, but you could do a shallow clone
git clone --depth 1 repo_url

would clone the repo but only take the last commit

 

Could you then push that to a new repo? Could be an easier way to do what I was describing above.

 

Unity Personal is Free
Unity Plus is $300/yr
Unity Pro is $1500/yr

Unity Personal allows you to generate annual revenues up to $100k
Unity Plus allows you to generate annual revenues up to $200k
Unity Pro has no limit on annual revenue

If you cannot currently afford the Pro version, you can use the Personal or Plus versions.

 

1500 used to last about two years, just saying.

 

yeah you could totally set the depth to the amount of commits history you want, then simply set the remote to a new empty repo and push.

Not really sure what the fuss is about in this topic, unity plus is rather affordable and there is no reason to use pro unless you are above the revenue cap of 200k. Also there is plenty of good providers for version control that are free to cheap.

 

And after that, the $750 upgrade price lasted another two years.

--Eric

 

Plus the extra if you wanted to develop on mobile.

 

Bah, that's just a passing fad.

--Eric

 

I'm happy with unity pricing.

 

That's...I mean...what? You wrote what appear to be English words, but combined like that, they don't form any meaning I've encountered before. I should probably ban you just to be safe.

--Eric

 

Git LFS and you are set, our repo is 20 gigabytes, no problem for git with LFS

 

Probably involves "git squash" an "git clean".

 

So did you get this fixed?

 

https://passingcuriosity.com/2017/truncating-git-history/

 

@angrypenguin I tried but since have been busy with other stuff. It turns out the library folder isn't in the git repo, however if we were to add that folder to the repo I think the import step in the loading process would be much quicker! I tested it, and it takes seconds instead of most of an hour. Its not even that big of a project yet xD

The library folder is ~700 MB though... not sure how we're going to manage that. We're using GitLab. Is there a limit to the size of your repo? Or does it cause a lot of latency/demand on the GitLab server too?

I still have to do some more playing around with the repo. Figuring out what the largest files are, and finding ways to reduce their size/download times. Shaders are a b**** to compile, I'll say that.

I have to say that the project is just sort of a mess. Spaghetti code is bad, but so is spaghetti OOP code structure. There is sooooo much coupling and the import/clone time takes so long that I am not inclined to work on it, and there is someone who doesn't know what they are doing and refuses to listen to anyone... but I didn't say that.

Additionally felt a bit bad about posting this thread. I did not do the proper research, and feel like I was just complaining. That's my bad.

 

You don't "manage that". You don't want to put your Library folder in Git.

You should only need to do a full import when you've done a full new clone. Any other time it'll just recompile scripts and import any new or updated assets.

If it's "not even that big of a project" it'd be interesting to know what's chewing up "GB with every commit". Unless I'm doing something crazy I find it difficult to chew up even a hundred megs in a commit. Most are kilobytes or low megabytes (and the latter only if I'm pushing textures and such).

Do you have huge light bakes you're inadvertently pushing every time?