Why we moved to Git LFS after a year (not entirely)

[Anton]

Spoiler: we still are going to use Plastic Cloud to store our raw assets in the cloud because we are all-remote.

 

We've chosen Plastic for our team because it looked like a VCS which can handle code and binary assets in one repository. At that time I was happy using Git for code but I was not sure about non-programmers and I wanted something more simplistic conceptually for them rather than Git.

One year passed. And it looks like our workflows where we use Plastic are more programmers-driven and programmers were not totally happy with Plastic. Here go biggest annoyances:

1. After we switched to Plastic this "Check Out" button appeared in Unity for every asset. Literally you cannot edit prefabs or script objects until you press this Check Out button, otherwise everything is grayed-out. The paradox is you have no this button in your source files (code) and everything works - why the hell you have to push it in Unity for every asset every time?

2. Branch Explorer is not readable at all compared to the common Git graph. You have no commit messages, you have to select a commit by hand to read its message in properties window. Branch names are poorly rendered too, do not try to zoom out. When you have 5+ people working in branches it becomes a mess. Finding a branch for merge is not as easy as in Git. I feel a real cognitive load when I do work with branches in Plastic.

3. Branches cannot be deleted. Think about it. (They say it is not a problem I do not agree. You have the Branches window and it displays an ever growing list of branches and sorting capabilities are limited.)

4. You cannot do partial commits or discards. I mean no way to commit only these two lines because you do not have a staging area (I found it an extremely useful concept in Git).

5. When you do a merge you cannot discard some changes (even files) because a guy who did the work failed here and there.

6. Plastic has lack of support in IDEs. The Rider plugin slows everything down and makes it unusable.

While a couple of points are of "this is not a Git" kind - I can accept it. Some are just a poor design choices or bad UX and because this is a closed proprietary system there will be no other better GUI clients ever!

 

A couple of words about moving away from the Plastic. It was pain in the ass too. It took almost a week of hacking to do fast-export right because Plastic exports a repository in a way which is not totally acceptable by Git. For example Git does not allow white spaces in branch names, Git has no operations for directories, Git has this concept of line-ending normalization while Plastic offers no rules for Line Endings and they become a mess. So it took a week from me to write and test python scripts to adjust our multi-gigabyte fast-export file for Git.

But as I said in the beginning we still will be using Plastic and Gluon as a large affordable storage. Thank you Plastic for that!

If you never used Git and you are a generalist or not a programmer and you like Plastic then stay with it!

[ollieblanks]

Hey Anton,

Thank you for sharing your experience with Plastic SCM. We are very grateful for all feedback as it helps us to identify things that we can improve.

Quote

1. After we switched to Plastic this "Check Out" button appeared in Unity for every asset. Literally you cannot edit prefabs or script objects until you press this Check Out button, otherwise everything is grayed-out. The paradox is you have no this button in your source files (code) and everything works - why the hell you have to push it in Unity for every asset every time?

This would only be the case if you have enabled the legacy Plastic SCM integration.  If this behaviour is not desired, you should disable the legacy integration by changing the mode back to its default value "Visible Meta Files".

This integration has now been superseded by the new plugin. I urge you to give it a try as it has all the same features as the legacy integration and more!

Quote

2. Branch Explorer is not readable at all compared to the common Git graph. You have no commit messages, you have to select a commit by hand to read its message in properties window. Branch names are poorly rendered too, do not try to zoom out. When you have 5+ people working in branches it becomes a mess. Finding a branch for merge is not as easy as in Git. I feel a real cognitive load when I do work with branches in Plastic.

We are always on the lookout for ways to improve the Branch Explorer. If you have any specific ideas about how this could be improved they would be very welcome.

If you need to see all comments at a glance (rather than clicking on each Changeset and viewing the properties for it), then the "Changesets" view may be a more suitable view for this use case...

Regarding the branch names when zooming out, I see exactly what you mean with this feedback. I will discuss this further with the development team and suggest that a minimum size is implemented for the branch names.

Quote

3. Branches cannot be deleted. Think about it. (They say it is not a problem I do not agree. You have the Branches window and it displays an ever growing list of branches and sorting capabilities are limited.)

This is excellent feedback. It is the Plastic philosophy that history should not be deleted or changed, but we understand there are circumstances where it may be desired or beneficial.

We are currently looking into options for allowing the trimming of old branches and content. I will be sure to bring up the points you have raised here as they are very valid points.

Quote

4. You cannot do partial commits or discards. I mean no way to commit only these two lines because you do not have a staging area (I found it an extremely useful concept in Git).

I may be misunderstanding your request here, but I believe this can be done. If you want to check in only the content in one file, then you can select only that one file in the Pending Changes view and check it in.

Another alternative would be to create a Gluon workspace for this repo, configure this repo to only download the content you need, make the two lines change and check it in.

Please do let me know if these solutions do not meet this requirement and why, because I would really like to understand what we could do to improve in this area.

Quote

5. When you do a merge you cannot discard some changes (even files) because a guy who did the work failed here and there.

A merge operation is an atomic transaction at the Changeset level (meaning it is "all or nothing" operation) for traceability and performance reasons. As far as I am aware Git handles merging in the same way. If this is not the case, please can you let me know how it can be done with Git?

 

Quote

6. Plastic has lack of support in IDEs. The Rider plugin slows everything down and makes it unusable.

Plastic has support for Visual Studio and Rider. The Rider plugin causing slow down is a known issue we are currently investigating. Sorry to hear that you were experiencing this behaviour.

Quote

A couple of words about moving away from the Plastic. It was pain in the ass too. It took almost a week of hacking to do fast-export right because Plastic exports a repository in a way which is not totally acceptable by Git. For example Git does not allow white spaces in branch names, Git has no operations for directories, Git has this concept of line-ending normalization while Plastic offers no rules for Line Endings and they become a mess. So it took a week from me to write and test python scripts to adjust our multi-gigabyte fast-export file for Git.

Can I ask the reason for using fast-export rather than GitSync? As far as I am aware, the issues you report are not present there and it may have been a more suitable alternative for your use case.

[Mikael Kalms]

I'm not the original author, but perhaps my commentary is useful:

On 5/26/2021 at 10:16 AM, ollieblanks said:

Quote

3. Branches cannot be deleted. Think about it. (They say it is not a problem I do not agree. You have the Branches window and it displays an ever growing list of branches and sorting capabilities are limited.)

This is excellent feedback. It is the Plastic philosophy that history should not be deleted or changed, but we understand there are circumstances where it may be desired or beneficial.

We are currently looking into options for allowing the trimming of old branches and content. I will be sure to bring up the points you have raised here as they are very valid points.

I think there are two different things at play here: trimming of old branches & content to reduce repository size, and trimming of old branches to make the repository easier to navigate. If the goal is to make the repository easier to navigate, then rather than making it easy to delete branches (like you would do in Git), I think a better option for Plastic would be to make it easy to mark branches as 'archived'/'inactive'.

On 5/26/2021 at 10:16 AM, ollieblanks said:

Quote

4. You cannot do partial commits or discards. I mean no way to commit only these two lines because you do not have a staging area (I found it an extremely useful concept in Git).

I may be misunderstanding your request here, but I believe this can be done. If you want to check in only the content in one file, then you can select only that one file in the Pending Changes view and check it in.

Another alternative would be to create a Gluon workspace for this repo, configure this repo to only download the content you need, make the two lines change and check it in.

Please do let me know if these solutions do not meet this requirement and why, because I would really like to understand what we could do to improve in this area.

Git power users want a finer granularity than "which of my currently checked-out files do I want to check in now?". They want to be able to implement a larger change to a set of files locally, and then check that in as a series of commits, where individual commits only involve _some_ of the changes from _some_ of the files. In other words, they want to be able to not only mark a set of files for checking in: they want to mark some blocks of code within the files for checking in.

[Oyvind]

On 5/26/2021 at 10:16 AM, ollieblanks said:

I may be misunderstanding your request here, but I believe this can be done. If you want to check in only the content in one file, then you can select only that one file in the Pending Changes view and check it in.

Another alternative would be to create a Gluon workspace for this repo, configure this repo to only download the content you need, make the two lines change and check it in.

Please do let me know if these solutions do not meet this requirement and why, because I would really like to understand what we could do to improve in this area.

I also wanted to comment on this as I find this fairly important to me, even though Mikael went over it above.

With Git, you have the opportunity to either stage (selecting what you want to submit for a commit) or undo individual lines or hunks (blocks of code, similar to how the Diff window presents all changes as many smaller groupings).

That made it very handy if you had been, say, debugging a problem and had added bunch of temporary logs during the process when trying to hunt down the issue and solve it.
After I'm done with that process, I would then ideally just checkin the actual changes that are relevant to the issue and then revert all the other changes that wasn't meant to be persistent.
With Git that's fairly easy as you'd then just select the line(s)/hunk(s) that are relevant, then undo the rest of the file. Or if there are many changes and I just want to undo a line or two, I could also do that instead.
You can see a simple example of this with visual tool (in this case, Git Gui) here : http://nathanj.github.io/gitguide/committing.html

As far as I can see with Plastic, this isn't possible and you're forced to go back into the text editor/IDE and undo the changes there.

Edit: Just discovered that the Rider plugin (which I had yet to try out) does support the functionality to revert a changes when diffing it, which at least helps. Would still be handy if this could be available inside the diff window

[gweronimo]

On 6/4/2021 at 11:55 AM, Mikael Kalms said:

I think there are two different things at play here: trimming of old branches & content to reduce repository size, and trimming of old branches to make the repository easier to navigate. If the goal is to make the repository easier to navigate, then rather than making it easy to delete branches (like you would do in Git), I think a better option for Plastic would be to make it easy to mark branches as 'archived'/'inactive'.

How we approach the second goal, in our workflow, is to (automated by a create-branch trigger) add a custom "branch-status" attribute to each branch. The default value of this attribute is "in-progress", and other values include "pending_review" and "completed" - we then use custom coloring and filtering based on this attribute. That way we can prune the Branch Explorer and Branches views to include only the active branches. Also, we've checked in the Branch Explorer rules for this coloring and filtering in the plastic-global-config repo, so all users get the same rules by default. 

[Energy0124]

Anton said everything I hate about Plastic SCM as a programmer and game developer, particular 3 to 6. I love that it is fast for binary, but not for other stuff...
Point 5 is particularly important to me.
It would be awesome if plastic scm is just like git, but centralized.
 

[ollieblanks]

Thanks everyone for the feedback! Its great to hear about people's plights with the tool so that we can review and improve.

@Mikael Kalms

Quote

Git power users want a finer granularity than "which of my currently checked-out files do I want to check in now?". They want to be able to implement a larger change to a set of files locally, and then check that in as a series of commits, where individual commits only involve _some_ of the changes from _some_ of the files. In other words, they want to be able to not only mark a set of files for checking in: they want to mark some blocks of code within the files for checking in.

Thanks for clarifying this request. I believe this would not be a trivial task, but a very good addition nevertheless. I will raise this with the team! 

@Oyvind, reverting a hunk of code can actually be done in the in the diff view that is nested in the Pending Changes view. Hopefully this is helpful to you.

 

@Energy0124

Quote

Point 5 is particularly important to me.

As I mentioned above, a merge operation is an atomic transaction at the Changeset level (meaning it is "all or nothing" operation) for traceability and performance reasons. Are you able to give a bit more context about how Git does this better?