How to collaborate...dropbox just broke everything.

Who cares? Git handles all this fine, we work on huge multiple GB Unity projects with GitHub and don't have any problems caused by 'bloat'

 

just going off what they say:
https://help.github.com/articles/what-is-my-disk-quota
https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699

 

GitHub's statement is too vague. They only claim to send out an email requesting you reduce the amount. It doesn't state whether or not they try to enforce the quota and it doesn't state whether or not the quota applies to all accounts.

For a company offering paid tiers, they aren't very clear about the limitations.

 

another option would be to split out some of the work. In the case of psd files maybe use base camp as long as they don't have to be in your project.

 

This is also interesting although I haven't tried it yet: https://github.com/alebedev/git-media

 

Same here, though I use Unfuddle rather than GitHub.

Having said that, what some people call a "big" project is likely far bigger than my typical multi-GB project. I imagine large studios easily getting into the 10s or 100s of gigs. And even without that, people using providers with smaller limits (eg: Bitbucket, which is intended for code, not content) will still hit them easily enough.

@bzor: I could be wrong, but I thought that Plastic SCM was just a front end, and used Git/Hg/SVN on the back end? If so, how does it impact 'bloat'?

 

this explains Plastic well: http://www.plasticscm.com/version-control-for-games.html

 

Ok guys, I'm sorry to necro this but I'm trying to figure out something out.

When should I use branching? I'm having trouble figuring out what exactly does a merge do. If I move on the master branch and make a script with function A in it, and the same script on the other branch has function B on it, what will happen after I merge?

Also, is it possible to have asset diff like terrain spotted? I mean I made a test with my friend where I made a terrain (pushed it when it was flat, he pulled it) and edited it in the middle, while he edited a corner. I was kinda hoping since asset serialization is forced to text, that once he pushed it it wouldn't override my terrain and instead merge the diff in the heightmap.

I guess I'd like to know if this is only useful for scripts and object settings, or can it work on asset manipulation. It's not a big deal but I'm just trying to figure out how the collaboration workflow will go.

From my understanding we should both work on a master branch, commit changes and push, bitbucket will find the diff and merge them. Or should one of us work on the master branch whereas the other one working on a branch.

For example if I was working on a character controller on master, and my friend worked on an enemy spawner on a separate branch (lets say I created only a character, and he created only a terrain), once we merge there shouldn't be any conflicts right? But what if we have something like a GUI on both branches, how will that work out?

 

Dont use dropbox. or make sure both teammates are not using the project at the same time. This is actually a case where you want your team-mate to live in a different time zone, you work in the morning he works at night.

 

If you both work on the same branch, and you both edit the same script file, and one commit is pushed by your colleague, and then you try to push your commit, the source control will try to 'merge' the two files like a zip, trying to add your changes and his changes together.

If the same lines of code are changed, and the source engine can't figure it out, it will notify you of a conflict, which you'll need to resolve manually line by line.

I'd suggest trying this out and seeing the results, to get more comfortable with the process.

Assets and Scenes won't be able to 'merge', they will always conflict in the above situation. As the source control engine can't merge binary files or files with special metdata (such as Unity scenes). So make sure you're not both working on the same scene or asset at the same time.

A branch can be used for many things. Usually if you're adding a new feature, which will require many commits, and you don't want to interfere with your main branch. When you are happy with the feature and it's functionality, and you now want to merge it back into the main branch, you can do one code/asset merge and conflict resolution. This also gives a much cleaner commit history.

Another common use for branches is making 'releases'. If you have a stable version 1.0 of your game, and you don't ever want to change it, but now you want to start working on version 1.1, you could create a branch called 1.1, and all updates for the 1.1 release happen on this branch. You don't ever need to merge this branch back into the 1.0 branch, as there is no need, it is a seperation of concerns.

BTW : I've found GitHub and SmartGit to be the best workflow for source control. SmartGit is very intuitive and well designed when it comes to having a 'UI' to manage your changes, and I've used many.