Gluon conceptually incompatible with "branch per task" - how can Devs and Artists work together then?

[Wolfram]

Hiho.

We are a team of Unity users, and just started switching from the AssetServer to Plastic SCM. So I learned about "branch per task", and came to appreciate the benefits of this concept.

Now we obviously also have Artists in our team, who shouldn't necessarily be bothered with the "full-fledged" client. Instead, you provide the Gluon tool.

However, Gluon knows nothing about branches, and it's not possible to configure it in a way that it works on an "Artist-dedicated" sub-branch instead of /main. So the whole concept of "branch per task" and keeping the mainline production-safe becomes moot. :-/

Isn't that a complete concept breaker? How do you suggest a team of Artists and Developers should work together with Unity and PlasticSCM then?

[manu]

Hello Wolfram,

we decided to stick gluon and the main branch together because artist can rarely "break the build", so artist can work with gluon and developers take the real potential of Plastic SCM by using branches and the merge system.

Artist rarely will want to branch since their content created can't be merged... png, mb files... 

I understand there're some cases where you want to use a different branch for the artist, I guess it's because you want to control how the content is delivered to the main branch, right?

You can use gluon with a different branch, no problem at all, you'll need to execute a CLI command and gluon will use that branch.

So for example, we have the "/main/Artist-Work" branch, you'll need to create a new Gluon workspace, it will point to "/main", open a command line tool, drive to the gluon workspace path and write the following command:

cm stb /main/Artist-Work

then back to gluon you'll be able to configure the workspace content and start working with gluon and the Artist-Work branch.

 

[jice_nolaroads]

hello,

i'm looking to do exactly that.
i presume it's "cm switch br:/main/Artist-Work" now because stb is marked "deprecated"

But theses commands do also a full update with switch
Is there any way to do that without updating branch to let artist configure their partial update with gluon ? or must they download all repo in theses cases only to not be on main ?

thanks.

[manu]

Hi there @jice_nolaroads

in order to prevent the full update you can do the following, I know it's not 100% artist friendly but it does the job.

1. notepad .plastic\plastic.selector (from the workspace root path)
1.1 If you have something like:

    br "/main"
    co "/main"

replace it with:

    smartbranch "/main/Artist-Work"

1.2 If you have something like:

    smartbranch "/main"

replace it with:

    smartbranch "/main/Artist-Work"

2. Open gluon and update... load... unload... what you desire.

[Mikael Kalms]

Related to your situation:

We decided to train everyone on our team (progammers, designers, artists) to use the full Plastic SCM client. We are working against Plastic Cloud. We are missing out on the simplicity of Gluon, and we are not using exclusive checkout at all, but it has worked out well for us.
 

Our process for a new developer is like this:

1. Begin by working directly against the main branch. Focus on the "Pending Changes" and "Branch Explorer" views. Do the first couple of check-ins in pairs until the developer is comfortable with checking in.

Programmers typically work against the main branch for a day or so, and then they go straight to task branches. Artists and designers typically work against main for 2 weeks - 2 months. After that, they are ready for step 2.

2. Talk with the developer about how he/she are doing single, large check-ins because the developer is afraid of breaking things for others - and how the developer sometimes loses local work (typically through mistakes in the editor when making a large change, etc). Talk with the developer about the conflict ("check in often is good: backup & share results" vs "don't break the build"). Talk with the developer about how there currently is no way for him/her to share results between two people or two machines (say, work machine + home machine) without also sharing it with everyone else on the project.

3. Set the developer up with a personal branch. Talk with developer about how checking in and merging now are separate steps; checking in to a separate branch only has upsides, and no downsides; merging is where care needs to be taken. Do the first couple of merges in pairs until the developer is comfortable with merging. Explain how "merge from main to your branch often" makes merging back less complicated. Explain how the "merge down from main, then merge up" philosophy makes merging less complicated.

Some of our artists choose to stop at stage 3. They want to work with personal branches. Those who want to move on, are ready for that after 3-6 months.

4. Talk with the developer about how their feature work is task oriented but how that structure is not reflected in the Branch Explorer - it's difficult to see where one effort ends and another ends in the project history. Explain the concept of "task branches".

5. Train developer in creating new branches for each major task. Small stuff can still go straight into the main branch. Discuss how to handle multiple overlapping tasks. Discuss how per-task branches help them organize their own work.

We have all our programmers, 40% of our artists and 50% of our designers using per-task branches. Remaining developers have personal branches.