Approach for initial setup of repos

[JEP]

I'm evaluating Plastic and have run into a question of how I should approach some project setup. We have local servers and a single office server (that will be our source of truth).

We have two developers trying it out, and they both currently have the same projects on both of their machines. We'd been using the (awful) built in Unity Collab to sync the projects. Now we want to get the projects in Plastic.

What I started with is create a local server repo for one of the projects, then pushed it up to the office server. Then the other dev created their own local one and pulled from the office server. But here's the problem. It took a while from me setting things up to get some time in their schedule to try it out. So now they have changes. How should this be handled? If shows them as being on changeset 0, but on the branch they pulled down its at changeset 3. If I say "update workspace to changeset 3" it blows away their files (we made that mistake on one project).

How should I have handled it?

[calbzam]

Hi,

- Plastic supports both centralized and distributed workflow:

Centralized: The developer workspace are directly pointing to the central server. they don't need to host their own local repos. Every change they perform will be one directly on the central repo.This is the workflow to use if you plan to use file locks.

Distributed: The scenario you are describing.Every develop has their own local server (and local repos) and they will be pushing/pulling to the central one.Similar to git workflow.

- If you are following a distribnuted workflow, what you describe makes sense. After the second developer pulls the repo, they can create a workspace pointing to this pulled repo and siwtch their workspace to the desired branch. Then they can perform as many changes as they need, and finally, push their local branch to the central server so it's available for the rest of the team.

The second developer needs to pull repo and switch the workspace to the changeset 3 before perform any change in their local files.

Regards,

Carlos.

[JEP]

The problem we ran into is that these repos are several gigs (thanks, Unity). There seemed to be no way to switch the workspace to a different branch, but tell it to not copy all the files out of the repo db and into the working directory, overwriting the existing changes.

[calbzam]

Why don't you use a centralized workflow so you don't need to push/pull branch with big assets?

Quote

 There seemed to be no way to switch the workspace to a different branch, but tell it to not copy all the files out of the repo db and into the working directory, overwriting the existing changes.

When you create a clean new repo and switch the workspace to a branch, if some files are already in your local path, they won't need to be downloaded. You can also use "cloaked.conf" if you don't want to download specific big files.

But if you have some changes you want to checkin, these changes need to be applyied in your workspace after the switch (after the workspace is pointing to a specific branch all the changes eprformed in thw workspace will be tracked).

Regards,

Carlos.