Official Choosing between Collaborate’s 1.2.16 and 2.0-Preview-15 Packages

We’ve just released an update to the Collaborate’s 2.0 package series, named 2.0-Preview-15. The package has two notable changes - it removes the “checking for changes” blocking dialog and also introduces a manual rescan button as the only mechanism for pulling in newly modified files. The full release notes can be found here.

Given this change in experience, the 2.0-preview-15 package will live alongside the existing 1.2.16 package as an option. Here’s how you can decide which to use:

• 1.2.16 is a good option for smaller projects or teams who do not mind the “Checking for Changes” blocking dialog box. The service will continue to automatically pull in newly modified files without additional action needed.
  
  
• 2.0-Preview-15 is a good option for larger projects or teams who found the “Checking for Changes” blocking dialog to be highly irritating. The service will no longer automatically pull in newly modified files. Instead, you will need to trigger a scan for potential changes via the “rescan” button. The rescan will not present a blocking dialog.

As we mention in the “The First Steps to a New Collaborate” blog post, 2.0-Preview-15 marks the end of the “old Collaborate” era. Both packages will be put into sustainment mode with a high bar for fixes. Moving forward, we will start fresh with a creating a new and highly improved Collaborate that is stable, feature rich and will work great with large projects and teams.

 

For large projects, what about some hybrid config that we could provide specific folders to be constantly checking for changes and others to be triggered manually?

Also,
I would add a rescan option on selected folders like you already have the See Diff and Revert opts

 

How come Git LFS manages to track changes just fine, but Colloborate 2.0 can't? Are there still large differences between Git LFS and Unity's Collab 2.0 backend?

Anyway 2.0 does look great, that little video of the new UI looks so much smoother Collab 1.0 ever was (die JavaScript die).

 

If I may ask, what is the performance of the two package options with respect to the 'long hang after updating' problem? For us, this is more frustrating than the 'checking for changes' issue. (Don't get me wrong, 'checking for changes' is pretty annoying, but *theoretically* it should only happen when I start the Unity editor in the morning. (The fact that Unity sometimes crashes and you have to restart, or the connection to Unity accounts is lost, makes it a lot worse. But that's enough parentheses))

The Long Hang (yes, capitals) happens after *every* update, and you cannot submit *anything* if you are not up to date, no matter how unrelated my changes are to the incoming updates. Does 2.0 help with this?

And then there is the 'Theirs Hang'. This does not seem to be quite as bad as the Long Hang, but still disturbing. The Theirs Hang happens if you select 'Choose theirs' to resolve a file conflict. I guess only noobs still use the 'Choose theirs' button, all the cool kids just click 'Choose mine' and then revert, both of which are nearly instant. How is 2.0 coping with this one?

 

Can we safely switch back and forth between the 1.2.16 and 2.0-P15 versions? At least once, to check which one actually works better for us in practice.

 

It doesn’t.

 

Dang it! But thank you for the reply

 

We tried 2.0 preview-8 and it actually did resolve this issue so I don't see why it wouldn't be the case with the newest version. However, you could never know what your current changes were and could even make empty commits because the editor just wouldn't update the state and different team members kept getting thousands of random changes in the project so we just rolled back to 1.2.16, the preview just seemed too unstable. We get 20 minute hangs with each update and if it's anything like that for you, it's probably worth a shot, maybe preview-15 won't be as messy.

Pro tip: When you open the project in the morning and are done checking changes, open the collab history and Restore to the latest update. You can update without the hangs until collab decides to disconnect or you have to restart Unity. Another thing to note is that the hangs never occur on OSX in our experience.

 

It does, it just lasts only a few seconds (which go away if you also do a restore).

 

I don't follow. Maybe Collaborate 1.2.16 doesn't have this option. My history looks like this:



Also, 'restoring' or 'going back to' are not very fast either, and of course you lose all local changes

 

You'd select Restore in the commit 5362 in this case and naturally lose your current changes as you said. We've already gotten used to this ridiculous workflow and always commit everything at the end of the day so that we can restore as the first thing after opening Unity. It's not fast, but the updates will be (as long as you don't disconnect or restart Unity).

 

Ah, and that will 'Restore' to the most recent version 5364 instead of 5362? Gotcha.

 

No, it will still restore to 5362 as expected. What I'm saying is if you do this kind of restore once, the regular update will no longer take forever and you can use it normally during that session (you won't experience "The Long Hang").

 

Ah!

That's pretty great. And that is why it is a pro tip!

 

Is there any chance you could show where the "rescan" button is supposed to be? I can't find it anywhere, my collab UI looks the exact same with 2.0-Preview-15 as it did with the non-preview version.

 

Hi @Nyphur, in the included screenshot you can see in the bottom right of the Toolbar the new Rescan button that you should see if you're using 2.0.0-preview.15. Make sure to restart Unity after updating the package to make sure that Unity loads the correct version of the Toolbar.

 

Is there anything I can do to recover from this?

Restarting Unity doesn't make it go away, restarting the computer doesn't make it go away.

I also occasionally get this error

Edit: Forgot my favourite

 

Thanks Ryan, somehow my version of Collaborate had reverted back to the previous package but still said 2.0 until I restarted. Upgraded again and I can see this button.

 

Hi @AcidArrow, for the first issue it looks like you have a locked index file that was left behind after a process crashed. Try closing your Editor, go into your .collab folder in the root of your project directory (it'll be hidden so you'll need to show hidden files in Explorer/Finder first), and delete the index.lock file. After reopening your project you should be able to continue using Collab normally.

As for the other errors you're seeing, those are one off errors that shouldn't be affecting any behavior on your end. If you're seeing them multiple times then please let us know so that we can investigate further.

 

Hi,
Because I start to have a stack of very bad experiences with packages being only out of preview in future versions of unity and not backported, I would like to know: is Collaborate 2.0 (non preview - verified, all that) confirmed to release in 2019.1 ?
I'm very interested into its new aspects and the work you delve into it.
But can I expect a real support of the package on that version of Unity ?
I have zero interest into going to 2019.2 or 2019.3 to update a package.
Thanks

 

Hi @Immu, I'm sorry you've been having poor experiences with preview packages so far. Our newest design for Collab has a tentative release for this August and we plan to make the package available for as far back as 2019.1.

 

Ever since we updated our project to use Collab 2.0 Preview 15, there's been two collabignore files. One is

Code (CSharp):

1. .collabignore

and the other one is

Code (CSharp):

1. collabignore.txt

. I've tried looking at multiple places but I can't find anything about what this new .txt file's purpose is. Is it safe to delete it?

 

With Collab 2.0 being based more on Git LFS, it's possible to commit folders and files outside of the Assets folder. That's why when upgrading to Collab 2.0 a new .collabignore file is auto-generated that includes additional rulesets to ignore folders that were originally ignored by Collab, such as the Temp and Library folders.

The collabignore.txt file is a backup of your project's original .collabignore file before the upgrade, in case there are any rules that you'd like to copy over into the new one. After you're sure that you're happy with the rules in your current .collabignore file then it's perfectly fine to delete the collabignore.txt file.

 

@ryanc-unity with Collab 2.0 is there a way to have a certain folder commit normaly but NEVER have it restored/overwritten when rolling back a commit? In other words I need to make sure that folder and its content gets backed up but it must never be modified to a previous state.

 

@tcz8 there is a way to specify a folder and its contents to not be overwritten when restoring or going back to a previous commit. The trick is to the use the .collabignore file.

What you do is create a folder, say it's called "IgnoredAssets". Publish your changes with that new folder. Then open the .collabignore file for your project and add "Assets/IgnoredAssets/" then save your changes. Go back to Unity and add any assets you want into the IgnoredAssets folder. They'll be ignored by Collab so any changes you make to them won't be committed. When you want to commit any changes in that folder, just comment out that rule in the ignore file with a "#" in front of it. Publish your changes, then uncomment the ignore rule and commit that change. That way, when you make some changes and then either press Restore or Go Back To, the IgnoredAssets folder will be left alone.

One caveat is with renames/moves. If you rename or move an asset inside of an ignored file and then Go Back or Restore then it's possible for the originally named asset to come back as a duplicate. But none of your actual work will be replaced. You might also run into instances after going back to an earlier commit that undoes your ignore rules where assets that should be ignored no longer have the gray crossed out 0 icon indicating that they're being ignored on them. To fix that just restart Unity.

 

Thank you, unfortunatly that's not what I was hoping for.

We developped our own project & team management software that runs inside unity.
Its turning out really good, CRM features comming in later with mail connectivity etc...

I was hoping to find a way to sync a local DB using Collaborate instead of using an external DB server. Would have made an awesome product for the store. Unfortunatly I dont think this will be happening.

A Collab API to push and restore specific files would be really usefull right about now (of course we would need a way to set those files to manual push & restore only).

 

I'll second this but go further: A Collab API to push and restore arbitrary serialized data, rather than just files, and to have this API optionally (but not as the default) able to use a different Unity Teams project ID than the project currently open in the editor. The request by @tcz8 would be a specific case of my more general proposal.

The reason for allowing a separate project ID to be specified within the API is that now we have a framework for building custom tools (either for intra-team use or to sell on the Asset Store) for organization-level management of asset and settings reuse across projects.

Here are some use-case examples:

• A team in the AEC space creates a tailored VR character controller rig for visualization walkthroughs, something that is more approachable to non-gamers and includes a built-in HUD for settings that is tailored just to the visuals and audio without game-oriented settings (and therefore would work on any archviz project). As they begin a new customer-facing archviz project, they import the character controller as a Unity package, and it fetches the latest version of default settings for specific supported VR hardware, automatically keeping that data up to date across all of the company's projects.
• A team making large open-world RPG creates a complex system (along the lines of Ativism) for managing game-related data tables such as character attributes, perks, equipment stats, quests, dialog, etc. This data is managed using the Collab API as a separate but connected project. They can now use the Unity editor to create a streamlined editing tool for writers and gameplay designers to work on the data independently of -- or ahead of -- the development of the game world.
• In a simulation or training environment, several different Unity projects are developed to simulate different types of construction vehicle or medical facility or factory process. Behind these projects is a common data resource that contains factual data about the simulation domain, such as pharmacological and physiological model parameters for the medical simulation (things that relate to the human body and are independent of whether you are simulating a surgical suite or a pre-hospital EMS trauma response).
• An organization uses Unity to develop in-editor tools for their resource and schedule management across all of the organization's Unity-related projects.

 

Last Package update is from May 30. Starts to be a bit long for something in preview.
Nothing new to share ?

 

So still no update on this... I've been told to look for great news at the end of the month. That was in August.

@ryanc-unity Whats going on?

 

I was expecting to see something announced at Unite Copenhagen last month, but still nothing. Any news on this?

 

Also interested in the status of the next update!

 

4 months without even a single reply.
Sadly, not the first time that I would say that, but the community management and overall communication of Unity to its (paying) customers really have a problem -_-.
After months I do expect a communication, even if the development is paused.
Tell us that at least we're being heard so we know we're aren't talking to the void.

Again, as a customer, I do expect professional behaviour.

Thank you.

 

So... well. Sorry for the upcoming rant, but I can't take it anymore with all those too-longs checking, errors on resolve, lack of clear UI, bad UX (everything has been listed above and in other threads), whether it's the old or the upcoming version, nothing is usable for serious production anymore.
I changed for Plastic SCM. I rather pay a new subscription at that point.
I learned it in a day, and the workflow is just 100x times faster. (plus we have all the additional features like branching and more)
Example: Here, apart from the initial pulling, any day work push/pull never more than 10 sec. (And I'm ith a 12Gb project) whereas it tooked several minutes with collab (which also did crash often and did the infamous reloading, rechecking of the data)

It's sad and frustrating, looking at the trust I once had in unity service.
Still holding a light for when some proper investment Unity will give to this mess. I still hope for the better, good luck.

 

@Immu, damn Plastic looks good, thanks for the recommendation.
I'll switch ASAP, I just can't trust anything collab related anymore, its a pretty dead service overall even if they improve it in the future I just can't trust they'll reach this level of quality Plastic looks like.

 

Just missing the fact that plasticSCM isn't in the provider list of Cloud Build, despite being an asset store partner who got recently featured in an article on Unity.com
That's sad. It requires manual send to CloudBuild via Gitlab x/ https://forum.plasticscm.com/topic/21450-unity-cloud-build/

 

I've been reading good thing about Plastic too. I'm going to take a look at it, thanks for mentioning.

 

We're so sorry for the delay in communication. The Collaborate team is in the middle of evaluating various options for the future of the product while also replacing the current UX with one that won't use an outdated framework that's being deprecated at the end of the year. I'm sorry for the lack of communication on the team's part and we will have more to say on what to expect from Collaborate in the near future.

I understand that this answer won't satisfy everyone but please know that the team just wants to make Collaborate as great as we all know it can be. Thank you for your continued patience and I hope to get back to you all soon with more concrete details.

 

So there is no (rough) estimate of when the new collab that was featured on the blog a few months back will come?

At this point I guess it won't happen till next year anyways, not even in a preview state?

Edit: what about the issues with the latest 2.0.0 previews? If I understand correctly the development of that collab version got abandoned, but latest preview is still bloated with issues and random "out of memory errors" that "fix themselves" with a unity restart which kind of get annoying and are definitely issues on collab's side.

And collab 1.x is still a pain in the ass with big projects (talking about 50gb+ projects) and checking at startup - even on an nvme ssd, can't even think about how it would be on a regular hard disk.

 

It does help to at least know someone's still out there working on this and that the project isn't quietly defunct. Thanks.

 

We have a hard deadline of getting the new Collab UX in by 2020.1. We'll have more info around that as we get closer to that version's release.

 

Well damn, I was really hoping this was happening in 2019.3. Would you recommend people use the Unity Accelerator?

 

Yes, I would highly recommend giving the Accelerator a try. In most of our tests we've noticed a decrease of 50-75% in Collab download times for anyone connected to the network that an Accelerator Agent is installed on.

 

Thanks for the answer. Just wondering, is branching support still coming? And will it be included at the release of new collab or will it come at a later point? (considering that its a rather big feature)

We didn't feel the need of branching until now really, but with our game's release date coming close (this winter), we really need branching to manage different versions (i.e. release version, betas, in development, different platforms etc.).

Anyways the 2020.1 release is a bit far for us now - if it comes around the same time 2019.1 came - so we will eventually have to switch to another version control system until new the collab comes.

 

Hi @Raul_MadGoat, thank you for your understanding. Yes, because branching is a big feature that we want to make sure to get right it will not be available at launch with the new UX in 2020.1.

We understand how vital branch support is for game projects and it is a very high priority for us after we finish moving to the new UX. If you'd like to switch to a different version control system in the meantime, Collaborate has an Export feature on the Dashboard for this purpose. Under the Collaborate tab, click on Storage and select "Start Export" to get the git repo of your project, along with its history.

 

Is that a nondestructive, idempotent export? That is, can I export existing projects to clone into local git for experimental purposes, where I don't want to use up our pool of Unity Teams space in the cloud for things that aren't critical? Or does the export process somehow mark the project as "not being in Collab now"?

 

Why not just buy out or officially partner with Plastic, and make that the formal version control solution, integrated into the Editor? Unity buyouts of products like TMP seem to have worked extremely well.

It seems like Unity are going for an incredibly stripped down and simplified version control solution, which teams very quickly outgrow and experience growing pains with all along the way.

Better to just have a slightly higher technical requirement to installation and use, and longer-term, happy customers. This seems to be what Plastic are already delivering, as far as I can tell.

Reality is that in the current games market (at least for PC), only relatively sophisticated games are making any money. Teams who are legitimately only using base version control (ie. no branching etc.) are not going to provide long-term revenue.

 

I was pondering making the same suggestion. I've never used Plastic, but it certainly looks interesting from what I hear from others and have read in their documentation. My company has used Git for many years for everything except Unity (the base Git, not GitHub or GitLab, and hosted on premises because of NDAs with our clients).

I'm the tech lead for my team, and right now we're using Collab because the GUI plugin for Git (which we tested extensively) wasn't quite fully baked enough for the non-programmers to use safely. Collab is working great for our artists, but the programmers like me are chafing at its lack of branching and tagging and lack of a CLI. It would be great if there was a really solid Git plugin with full Unity corporate support, that wasn't tied as closely to GitHub's cloud offering as the current plugin is. (In fairness, GitHub is kind enough to offer their plugin for free, so I'm not faulting them for favoring their services in a reasonably-nonintrusive way.)

One thing that appeals to me about Plastic is that -- at least if their web site's claims are true -- it can interoperate smoothly with Git in both manual and automated interactions. It might be a nice compromise solution for us to have a friendly GUI for the artists and a solid CLI for programmers.

Perforce, which has built-in support in Unity, is something I've been using for a client project for several months. I don't dislike the product, but it's rather painful to use it on large projects across a WAN due to it being very network-chatty from Unity even when I'm not actually "doing version control" things. If I run the P4V or P4C clients on the same depot, however, things are pretty fast. Even with "async" mode on, the Unity editor still becomes unresponsive for a minute or two at a time if I check out, move,or delete a folder or move changes from the default changeset to a custom changeset. Since our team are located in different geographic regions, I don't think Perforce would be a good choice for us. (I will, however, give kudos to Perforce for having pretty responsive tech support.)

Collaborate has worked well for us up to a point. We've had some issues with corrupted data and having to delete and re-download the entire project, which hasn't been *too* bad because our internal projects tend to be smaller than our client projects. And I'm glad to hear Unity is taking the time to add branches and other important things, and to rebuild the code from scratch to make it solid from the foundation up. My only question is, by the time that's done, will Unity as a company have invested more resources than it would have taken to partner with, and integrate, Plastic, or to develop a really solid front-end to generic Git and its derivatives?

 

After Collaborate corrupted multiple important files, and doesn't allow a push to be deleted, I've started the process of moving to Plastic SCM. I'll update folks on the process.

Collaborate is really only good for a single user, as an upgrade from backups via Dropbox or Google Drive (It shouldn't be called 'Collaborate', it should be called 'Backup'. If you have a small team (even freelancers) I would not recommend using it.

 

Collab is getting worse and worse.
Im using collab 1.2.16 with Unity 2018.4.11 LTS and Im facing this error several times per day:

ExternalAPI::Failure: A request to Unity accounts has failed with HTTP status 401 Unauthorized. Please try again. If you continue to see this error, please restart Unity.

Most of the time this cause a forced “Checking for Changes” blocking dialog box.
This is not even recognized as a bug by unity staff.
https://forum.unity.com/threads/col...ce-has-not-changed.468150/page-2#post-5081681

 

Just for reference, exporting takes a loooooooooot of time with big projects (45GB) with a big history. At first I thought the export just doesn't work but after 2 hours it finally went from 0% to 1%... I guess it will take too long for us to be feasible. Probably going to start a fresh git with the local unity project and ditch the history for now...