At a loss of what to do and can not figure out a workflow for plastic...

[jasonyak]

I've just spent another two days trying for the second time trying to figure out to use Plastic on a mac... and I think Im about to fly the white flag. It's been the most convoluted and unintuitive process, nothing has been obvious of how or what I should do. I've used SVN and GIT, and obviously plastic is closer to GIT.. but this seems so much harder to use than GIT. 

 

When I first opened it it gave me a welcome to plastic wizard panel to join a cloud project. But once I've closed this there's no way to access it again. I finally figured out what the wizard was doing do me so that I could copy the setup for test purposes. 

 

The biggest problem is that I've been unable to figure out what the general work flow is to plastic. I'm constantly confused and can't find a workflow that works consistently. To do some tests I created a cloud repo, then I created two local repos to simulate two users trying to feed in to the one cloud repo. So then I created two workspaces, one for each local repo. I also created two sync views, one for syncing from local workspace1 to the cloud repo, and another sync view for syncing from workspace 2 to the cloud repo. In workspace1 I added a folder called folder1, and then in workspace 2 I added folder2. I checked in folder1 to workspace1, then in the sync view for workspace 1 I pushed this to the cloud. Then in the sync view for workspace 2 I pulled from the cloud. At this point I thought that folder 1 would appear but no.. it's created a branch??! why?! I don't get it. Why wouldn't workspace 2 thats on the main branch just get the changes from that branch. What am I missing? Instead you then have to go in to the branch explorer and do some merging. Coming from git I've only had to merge branches that I decided to create, they weren't automatically created for me. How do I just check in some files to the main  branch and a user who's also on the main branch can just update and get those new changes? 

 

I then thought I'll try and skip having the local repo and that all workspaces feed directly in to the cloud repo, but that doesn't work out either. I did some simple tests where I have a png file in the cloud. I then modify this png in both workspace 1 and 2 to simulate two users having changed the one file. I then checked in one of them, then in the second workspace I could not checkin nor update the workspace due to the clash and the error messages were not at all helpful to understand what was wrong ie. when committing large amounts of files and various users getting these message I don't know how they'd know what to do to resolve it. 

 

I feel like I've tried to read every help doc available and the getting started macplastic videos, but nothing is making the general workflow any clearer. Macplastic is also freezing on me every half hour or so to top it off. 

 

A side question, does the Unity plugin work like Gluon that it commits directly to the cloud or does it only commit to the local repo? because if the latter how would checkouts work so that they lock files for other users unless you checkout and then sync with the cloud repo.

 

Sorry... Im so lost. Any help to unravel this all would be appreciated.

[psantosl]

Hi Jason,

 

Apologies for not reaching you sooner.

 

Please find my answers below:

 

> I've just spent another two days trying for the second time trying

> to figure out to use Plastic on a mac... and I think Im about to

> fly the white flag. It's been the most convoluted and unintuitive

> process, nothing has been obvious of how or what I should do.

 

Ouch! So sorry to read that! :'( We try hard to make it simple, but it is obvious that we failed.

 

Let's see what we can do, I keep reading:

 

 

> I've used SVN and GIT, and obviously plastic is closer to GIT..

> but this seems so much harder to use than GIT. 

 

Yes, it is much closer to Git. Plastic branches are closer to Git ones than SVN, in fact, they have nothing to do with SVN "branches as directories".

 

Regarding the "much harder", well, being simpler is our key selling point . So obviously we're doing something wrong with you.

 

> When I first opened it it gave me a welcome to plastic wizard

> panel to join a cloud project. But once I've closed this

> there's no way to access it again. I finally figured out what

> the wizard was doing do me so that I could copy the setup for

> test purposes.

 

That's a very interesting point. Yes, indeed, we just show the "first steps" panel when there's no previous configuration. We thought once you get used to Plastic, this "first steps" things won't help.

 

At the end of the day all it does is creating a repo and a workspace... But, you know, all in a single place.

 

> The biggest problem is that I've been unable to figure out

> what the general work flow is to plastic. I'm constantly

> confused and can't find a workflow that works consistently.

 

Ok, let's see if I can throw some light here:

 

* Repository => it is the same concept as Git and SVN => the place where everything is stored. Unlike Git, repos are NOT stored inside a ".git" thing on your working copy, but separately on "the server side".

* Workspace => your working copy. Here Plastic is closer to SVN: you can have many workspaces working on a single repo. There's no 1-1 binding like in Git.

 

* Plastic can work centralized (SVN style) and distributed (Git style). It means we can do both "checkin-style" and "checkin-push-style" workflows. Is that clear? We give choices, then you can take advantage of them.

** Centralized: you have one (or many) workspaces locally, but the repos are somewhere else on your server. SVN style. Good for simple workflows, artists, and anyone who don't want a local replica.

** Distributed: you have local repos on your machine cloned/or partially replicated from a central server (which can be cloud).

*** Distributed means you have a tiny Plastic server on your laptop, but from a logical point of view you can just assume you just have local repos. That's all.

*** In "cloud mode" we recommend to use distributed model, because Cloud server doesn't allow merging (it asks you to merge locally, then push). You can checkin directly, though.

 

> To do some tests I created a cloud repo, then I created two

> local repos to simulate two users trying to feed in to the

> one cloud repo.

 

Ok, sounds good so far.

 

> So then I created two workspaces, one for each local repo.

 

Fine too.

 

Remember you are not tied to 1-workspace per repo like in Git. You can have many workspaces to the same repo if needed. But yes, what you did was right.

 

> I also created two sync views, one for syncing from

> local workspace1 to the cloud repo, and another sync

> view for syncing from workspace 2 to the cloud repo.

 

Well, here comes one misunderstanding: sync views ARE NOT for workspaces, but for repos. You "sync" local repos with "cloud" repos. Nothing to do with workspaces.

 

Do you follow now??

 

You can push/pull branches with right click on the Branch Explorer, or on a branches list, but in order to sync an entire repo, you can also do it with a sync view.

 

But it is a "server side" (repo side) operation: sync = push/pull branches. That's all. NOTHING to do with workspaces.

 

 

> In workspace1 I added a folder called folder1, and

> then in workspace 2 I added folder2.

> I checked in folder1 to workspace1, then in the sync

> view for workspace 1 I pushed this to the cloud.

> Then in the sync view for workspace 2 I pulled from

> the cloud. At this point I thought that folder 1

> would appear but no.. it's created a branch??! why?!

> I don't get it. Why wouldn't workspace 2 thats on

> the main branch just get the changes from that branch.

> What am I missing?

 

Ok, it is very simple:

 

* You started in changeset zero.

* The two developers added changesets, in 2 different repos, after cset 0.

* Then you need merging. You would need merging in Git too.

 

I believe you would be better served with a single repo to start testing, then understand well how it works.

 

The behaviour you expect happens when you work on single repo, but since you are using 3 repos (2 locals and a cloud one), you are creating changes concurrently, so the ascii brex would be:

 

-- cset 0--- cset 1 (done in wk1)

     |

     ----------- cset 2 (done in wk2)

 

cset 2 parent is cset 0, not cset 1, that's why we create a "subbranch". It is exactly the same as "git fetch", but since Git concept of branches is slightly different (commits in git can be in MORE than 1 branch at the same time, and this can't happen in plastic), we create this.

 

More here: https://www.plasticscm.com/documentation/distributed/plastic-scm-version-control-distributed-guide.shtml#Replicationindetail

 

But, this is a rather exceptional situation: normally you would be using different branches locally, not everyone on main.

 

> Instead you then have to go in to the branch explorer

> and do some merging. Coming from git I've only had to

> merge branches that I decided to create, they weren't

> automatically created for me.

 

Well, AFAIK you just see a "sub-branch".

 

In case you are seeying really "new branches", then something different might be happening:

 

* You create repoAA locally => and populate it.

* You create repoBB locally => and populate it.

* You push the 2 repos to the same "cloudrepo@cloud".

 

* Then you get these "new branches".

 

Why?

 

Because you are pushing 2 different, unrelated repos, to a third one.

 

Way to do it:

 

1. Create repoAA => populate it.

2. Push it to cloud.

3. PULL from cloud to repoBB => now you are on the same objects, using the same GUIDs. I mean, cset 1 created on repoAA will be the one pulled here.

4. Make changes on repoBB, push pull, and do the same on repoAA, now you are certainly using the same objects.

 

Every object in Plastic is identified by a GUID, this is also different than Git (where they use a SHA1). This is what makes Plastic merge system better than Git... but yes, you have to slighly understand how it works at first.

 

> How do I just check in some files to the main 

> branch and a user who's also on the main branch

> can just update and get those new changes?

 

Described above now

 

 

> I then thought I'll try and skip having the

> local repo and that all workspaces feed

> directly in to the cloud repo, but that

> doesn't work out either. I did some simple

> tests where I have a png file in the cloud.

> I then modify this png in both workspace 1

> and 2 to simulate two users having changed

> the one file. I then checked in one of them,

> then in the second workspace I could not

> checkin nor update the workspace due to the

> clash and the error messages were not at all

> helpful to understand what was wrong ie.

> when committing large amounts of files and

> various users getting these message I don't

> know how they'd know what to do to resolve it.

 

You can indeed have your workspaces directly pointing to a cloud repo.

 

Indeed, this is the recommended way to work with Gluon (our UI for artists) together with locking, to avoid having to merge unmergeable files (like pngs).

 

More: we have a collection of short youtube videos showing how to start working with Cloud Edition: https://www.youtube.com/playlist?list=PL29P1RRr5_NyA1OBHIi1Z4PmflQLVDgCE

 

> I feel like I've tried to read every help

> doc available and the getting started

> macplastic videos, but nothing is making

> the general workflow any clearer.

 

Well, obviously we failed to explain it. What you are trying to do is so obvious and simple that we MUST have some mistmatch trying to explain it. This is what the videos do.

 

I hope my explanations above help you finding the "tick" we missed to explain before.

 

 

> Macplastic is also freezing on me every

> half hour or so to top it off.

 

We need more info about it. Definitely this is not something we are aware of. Would you mind if our support team contacts you?

 

> A side question, does the Unity plugin work

> like Gluon that it commits directly to the

> cloud or does it only commit to the local repo?

> because if the latter how would checkouts

> work so that they lock files for other users

> unless you checkout and then sync with the

> cloud repo.

 

It works in 2 modes: gluon mode (what you mention) and regular mode => which is ok for developers working distributed and NOT locking files.

 

Thanks for your time and feedback.

 

pablo

[manu]

Hi!

an update! although we recommend to have a local server or an on-premise server in order to merge your branches (performance is going to be much better) we do now support the merge operation for the cloud repositories.

So, you can now directly work with the cloud for all the Plastic SCM operations