Lazlo

Hi Carlos, Checking in on the UCB options as I promised. We're now at the stage where we have to implement a Unity Cloud Build solution. Has there been any progress on the Plastic or Unity front in the last 3 months? Thanks! Lazlo

Hi, sorry for bumping this -- I'm attempting to rename a repository but I also get the repository not found error. I managed to fix it by renaming it manually inside: The GUI plastic.workspace plastic.selector syncviews.conf hidden_branches.conf replicationsourcesinfo.conf plastic-guihelp.conf guivisualstate.xml It would be great if there was a warning that renaming a repository was not a supported operation from the GUI. Or in fact, just disabling it altogether, as it does not rename it properly everywhere at once.

Can we start a pool of sharing those? Here are mine so far on this computer: BrExTipCustomColors BrExTipUseTheSearch GluonWkExplSuggestConfigure GluonWkExplTipUseHistory PlasticPendingChangesAddedDeleted PlasticNewVersionAvailable PlasticPendingChangesSlowTooManyPrivates PlasticPendingChangesSlowMoveCalculation BrExTipOnlyRelevant PlasticPendingChangesWithAdded PlasticPendingChangesMovedFilesAndDirectories PlasticPendingChangesEmptyState PlasticWkExplExplainSearch I work on 4 different computers. Each of them gets the same sets of help tips every time. I'm used to Plastic now. They just distract me and take 50% of the screen every time for no valuable new information. I understand you want to bring contextual help. Maybe a small (max 32px high) banner or notification at the bottom right of the screen could appear when help is available instead? And let users click it if they feel like it's valuable to them. I also want to reiterate that there should be an option to disable all tips, globally, in one click. Whenever I set up Plastic SCM on a new computer, I have to endure those tips even though they are useless to me.

Hi Carlos, Thanks for the confirmation. We're currently trying to avoid having a local server or build machine, hence why we're interested in Plastic Cloud and Unity Cloud Build in the first place. At this point after your help on the forums in the last few days, the possible options I see for pure-cloud hosting and build are: Native support for Plastic in Unity Cloud Build (ideal) GitServer support for Plastic Cloud (very easy) Git LFS support for GitSync (clunkier but manageable) As I understand all three options are on Plastic's roadmap but none are available for the time being. I took some head start for evaluating this so it's not urgent yet, but I'll re-evaluate this issue in late-February / early-March. If none of those solutions are available then, we'll probably switch to another VCS like Perforce or even just Git LFS. I don't mean this as a threat, I think Plastic is superior for game development for every other reason, but sadly Unity cloud build is a non-negotiable part of our pipeline.

Hi Carlos, Thanks for the precision. I understand now that this was designed for the distributed workflow. GitServer seems amazing for our ultimate goal (using Unity Cloud Build!). Is there a way of enabling GitServer on a Plastic Cloud repo? This way we could simply point UCB to the http:// or git:// URL of the Plastic Cloud GitServer and it could work out of the box.

Does that mean that it's impossible to GitSync from two different computers without duplicating the Plastic repo? Even if both computers sync from Plastic Cloud <-> Git host directly (not replicated), and if they both use the exact same login information for the Git host? This is what I was hoping to do. We have more than one developer on the team who would need to sync to Git. And even if we did not, it feels kind of weird that I have to be on the same machine to run the Git Sync every time or else my repo is doomed (what if that initial client machine becomes permanently unavailable, for example? then we can't ever Git Sync again?).

Hi Carlos, Thanks for the precision. Some questions: Is there a way to toggle a "one-way" sync from Plastic to Git, kind of a "push-only"? In order to avoid this situation above, which I've had to fix 3 times already trying to understand how to setup GitSync properly. What determines whether a Git commit matches a Plastic changeset? I'm confused here because I thought the commits/changesets would be recognized as identical, since we're syncing from the same Plastic and Git repos, but just with a different login. Is the login data also used as a unique identifier? Is there a terminal command that can help me delete all children changesets faster than one by one through the UI?

Now to fix this I could start over, with a new git repo, deleted git-sync attribute, deleted git sync localappdata files, again. But is there a way to fix my duplicated head in Plastic without deleting each changeset one-by-one?

Hi, I set up GitSync to work directly between a Plastic Cloud repo and a Bitbucket host. After the initial tests worked, I created a new Bitbucket account with more restricted permissions for our bot instead of using my main account (because AFAIK SSH or 2FA is not supported in GitSync, which was not secure). Basically, all I did was change the batch file I had created from: cm sync repo@org@cloud git https://old-bitbucket-user@bitbucket.org/org/repo.git --user=old-bitbucket-user --pwd=old-bitbucket-password To: cm sync repo@org@cloud git https://new-bitbucket-user@bitbucket.org/org/repo.git --user=new-bitbucket-user --pwd=new-bitbucket-password When I ran the second command, I got warned that there already existed sync files and it refused to execute. The warning suggested that I could manually them in %LocalAppData%, which I did. After deleting the sync appdata files, the sync ran, but it created a duplicated head on the repo. I'm confused because the changeset GUIDs should be exactly the same, as they're the same repo after all. Is it because the https:// URL changed?

For example, in Git, you can push tags as-is.

Hi, Thanks for the precision. Can I post this as a feature request then? We have someone on the team who has a "management" role for the development process that is likely to label changesets for "bookkeeping" purposes with our issue tracker and release cycles, but they likely won't be creating new changesets of their own. Currently, there's no way for them to do that kind of work and share it with the team unless they create dummy code edits that pollute the repository just to force a sync.

Thanks, I'll create a batch file then. Unfortunately I couldn't find a Git hosting provider that supports >10GB repos and >100MB files without LFS enabled. They all offer paid data plans that could scale to these levels, but only for LFS enabled repos.

Oh also, re: the reasoning for the limitation I understand, but somehow it didn't keep us from creating a duplicated head. The workflow was: Replicated repo on Machine A Replicated repo on Machine B GitSync from Machine A GitSync from Machine B

Hi Carlos, thanks for the quick reply. I'll recreate a new Git repo on my provider. Is there a way to Git Sync between the Cloud repo and the Git host from the GUI without having to download the files? (Sometimes it's multi GB projects for us). (Basically this other workspace setup would only be to trigger the git sync). Otherwise I'll just create a batch file to run the sync.

I managed to pull by also deleting the git-repo-sync attribute from my repository. Not sure if deleting the %LocalAppData% folders were needed. I'm still curious about how to sync a cloud repo to git from the GUI though!