Hi Unity! Just wanted to say thanks for including our team in the beta for Collaborate, we are really excited to have integrated version control and collaboration tools. For reference, our team has experience working with GitHub and Perforce, and we store nightly backups in the cloud via OneDrive, Google Drive, and local hard drives. We are going to be posting our experience with Collaborate here since we are respecting Unity's desires to keep this a closed beta, as well as so that Unity can find out about what bugs we find as progress on the game takes place. I'm tagging all of these posts with [Iris] after our game, so it's easy to search for later. Background Just to give a bit of background on the project we are working on: it's an RTS game named Iris Burning, in which players are pitted against one another in multiplayer (2-4 players) or single-player matches to usurp territory and control a central market of Iridium, the third-rarest metal known to man. Players who control more of the iridium market have more leverage over the market price, and can thus drop the price of the central market (thus hurting other players' income), in addition to just straight-up attacking each other's supply lines with infantry, tanks, mechs, and support vehicles. There is also a miniature stock market that allows players to speculate on "companies" that represent perks and extra add-ons and side-quests for the player to tailor their business interests to a particular strategy, military or otherwise. Iris Burning is scheduled for a mid 2016 Kickstarter campaign, a March or April 2017 release date, and is currently manned by core team of about 8 people, with 36 total credited contributors. Initial Concerns We were originally going to use Perforce as our version control, but after seeing Unity's GDC presentation on Collaborate, we were convinced that this was probably a better option, primarily due to the likelihood of merge conflicts corrupting prefabs and compounding the number of times we have to rely on backups when using Perforce. Speaking with Unity personnel named Ethan and Dave at GDC convinced us that this was the best action to take, so we signed up and waited. Initial Impressions Booting up the editor for the first time, after waiting on the initial reimport of the project folder, I noticed that Collaborate was already jumping on the opportunity to prompt me to do setup. During this time, the editor froze and became very unresponsive at an intermittent frequency. The main game scene has lots of foliage using a wind shader that does simple sine-wave vertex deformation, and this was still rendering correctly in realtime, so it was the editor UI thread that appeared to be hanging. I was able to eventually get the Collaborate pullout menu showing, although it seemed to be accepting keystrokes at the same intermittent rate as its responsiveness. Eventually, I was able to peck the words "Initial commit" into the changelog, and press the magic button, and all was well: the upload commenced, and finished in a reasonable hour and a half. After this, the intermittent freezing stopped. For a large-ish project such as ours, upload times are slow. We have about 25Mbps upload speed in the main studio, so we expected it to be such. However, our download speed is more than double this, and for some of us on the same (non-wired, LAN) connection, even when running the downloads one computer at a time, we found it to be very sluggish (a 4.6 GB project took nearly 3 hours to download). This is not a major concern, but something of note. Actual Collaboration We published our first commit, and we were able to sync it across all the other machines, who were able to verify the changes were successful, make their own changes, and publish counter-changes. Awesome! This is enough to get us started, and not having to worry about corruption is very nice. We still run nightly backups with redundancy just in case, but having a cloud-backed project is really quite a worthy luxury. First Bug I have only one actual bug to report thusfar: When publishing a commit, if you have newlines (Return key, or \n character literal) in your commits, they do not display correctly in the changelog. So if your changelog has - bulleted lists like this - to indicate multiple changes - in case it's a larger, sweeping commit it will end up looking like - bulleted lists like this\n- to indicate multiple changes\n- in case it's a larger, sweeping commit. It's annoying, cosmetic, and probably easy to fix, but it needs to be said. I'm not sure if there are places for me to file bug reports, but I'll put them here just in case so someone sees it.