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

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.

 

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,
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

 

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?

 

@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.

 

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.

 

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.

 

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

 

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.

 

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...