Changing git sync login creates duplicated head

[Lazlo]

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?

 

[Lazlo]

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?

[calbzam]

I'm afraid all the repo content is duplicated  

The only way to recover this repo is manually removing all the duplicated changestes one by one.

Regards,

Carlos

[Lazlo]

4 hours ago, calbzam said:

I'm afraid all the repo content is duplicated  

The only way to recover this repo is manually removing all the duplicated changestes one by one.

Regards,

Carlos

Hi Carlos,

Thanks for the precision. Some questions:

1. 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.
2. 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?
3. Is there a terminal command that can help me delete all children changesets faster than one by one through the UI?

[calbzam]

Hi,

Quote

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.

I'm afraid the sync is performed by default in both ways. But if you always perform the oepration from the same client you shouldn't need to recreate the repos. This is the key to avoid breaking the repo (duplicating the repo history).

Quote

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?

The mappings folder created in your client is what determines if a commit/changeset was previously synced. This way, if some commits/changesets where already synced, they won't be tried to be synced again. 

Or are you refering about how Plastic is handling the user names when syncing commits/changesets in both ways?

Quote

 there a terminal command that can help me delete all children changesets faster than one by one through the UI?

You can use the "cm changeset delete" commands. You will also need to go one by one.

Regards,

Carlos.

[Lazlo]

21 minutes ago, calbzam said:

The mappings folder created in your client is what determines if a commit/changeset was previously synced. This way, if some commits/changesets where already synced, they won't be tried to be synced again. 

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

[calbzam]

Quote

 

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

 

The GitSync is a client side operation and the mappings are created on the specific client you run the initial sync. Some of our customers use a Plastic client installed on the server machine. This way, the operation always run from there and the gitsync mappings are more dafe.

As rule to avoid duplicating the data: don't run the gitsync operation from a client machine if it doesn't contain the mappings folder. Otherwise, the repo history will be duplicated.

If you run a  gitsync operation without the local mappings folder, the git repo or the Plastic repo needs to be empty. Otherwise, the repo history will be duplicated.

Quote

This is what I was hoping to do. We have more than one developer on the team who would need to sync to Git

Is this second developer hosting their local repos? In that case, they will be able to configure gitsync between their Plastic local repo and the git repo and host their own mappings folder.

But if you are not using local repos (distributed workflow) and all the developers are using the same central Plastic repos, the gitsync operation needs to be run always from the same machine. You can do it from the server machine via automated script.

PD: By the way, not sure if you are also aware of the GitServer feature:

https://www.plasticscm.com/gitserver

Regards,

Carlos.

[Lazlo]

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.

[calbzam]

Quote

GitServer seems amazing for our ultimate goal (using Unity Cloud Build!). Is there a way of enabling GitServer on a Plastic Cloud repo?

I'm afraid it's not available for Plastic Cloud but it's on our roadmap to support it. You can also install a hosted Plastic server (that is a clone of the cloud one) only for Unity Cloud build purposes. The setup is a bit more complicated but it may also work for you.

Regards,

Carlos.

[Lazlo]

9 hours ago, calbzam said:

I'm afraid it's not available for Plastic Cloud but it's on our roadmap to support it. You can also install a hosted Plastic server (that is a clone of the cloud one) only for Unity Cloud build purposes. The setup is a bit more complicated but it may also work for you.

Regards,

Carlos.

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:

1. Native support for Plastic in Unity Cloud Build (ideal)
2. GitServer support for Plastic Cloud (very easy)
3. 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.

[calbzam]

Let me share your feedback with the team. Hopefully we can provide a solution in the near future.

Regards,

Carlos.

[Lazlo]

On 1/20/2020 at 7:59 AM, calbzam said:

Let me share your feedback with the team. Hopefully we can provide a solution in the near future.

Regards,

Carlos.

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

[psantosl]

We are on it. We expect to have UCB support real soon.