Plastic SCM 3 - A Comment on Usability

[Byron]

Hi,

This text aims to share my experiences with Plastic so far. They might be useful to the developers and managers at Codice Software who wish to improve Plastic and make it more usable, opening it up to a broader audience. As these 'experiences' seemed to pile up recently, I feel the urge to share them with others, maybe I learn what I did wrong on my side, maybe everything is fixed in Plastic 4. The following text refers to Plastic 3, version 4 doesn't yet work for us.

Why Plastic ?

The reason we tried to develop using Plastic 3 in the first place was our need to go with the time and get rid of our SVN based repository. We wanted an SCM which allows easy branching and merging. For our purpose, a centralized system is fine, and Plastic does model that natively with its explicit client and server. A decentralized or offline workflow would be nice, but its not required for us by any means. Of course plastic can do replication, yet I always found it too complicated to use so I decided not to get into it.

The head of our development team put huge emphasis on a usable graphical user interface, which might boil down to the branch explorer which seemed to have sold plastic to him. He likes GUIs, and for that particular purpose I admit I do like GUIs as well. Other things which seemed nice are the integrated review system and the graphical and built-in merge capabilities.

What actually sold me were some blog posts which showed that you guys have a thorough understanding of destributed SCMs. These guys probably knew how to do it, I thought, so I felt comfortable with endorsing Plastic to him with just a few words. When I did that, I didn't really think that we, and I, would ever end up using it, I was seriously surprised.

In the first days when I had to use Plastic, I thought there was a certain irony to it, considering I disliked every piece of it, yet I was the one who laid the foundation for its use in the first place. That suffering was self-made, at least I could only blame myself.

The Good Things

Good things come into my mind easily when comparing Plastic with Subversion, or when comparing the GUI of Plastic 4 with pretty much anything else out there which is not github.

• Checkouts are very fast (compared to subversion).
  
• Branches are easily and quickly created and actually usable (compared to subversion).
  
• merging branches back and forth is working well (compared to subversion).
  
• The GUI has the potential to considerably lower the learning curve.
  

Things which might need improvement

All the things following are an issue with Plastic 3. Some may have already been fixed in Plastic 4.

The issues are sorted so that the most annoying are listed first.

branch explorer is about 5 minutes behind

If you create a branch for instance, you will not see this branch in the branch explorer. Instead, you have to go to the 'Branches' list, search the branch you just created within the 100 ones already there, and switch to it. All this of course is only necessary because there seems to be no way to say "create branch ... and switch to newly created branch".

The first time I ran into this I created a new branch and thought something was wrong as I didn't see it show up there. One of my first operations already caused plenty of confusion.

GUIs are only production-ready on windows and instable on OSX and Linux

Probably due to mono, the open source multi-platform .NET implementation, the GUI on OSX and Linux tends to be very instable. They can crash at any time when handling user input, which gets worse due to the fact that it actually freezes. The freeze is due to gdb which seems to be started automatically, which holds the program in limbo. The only way to get rid of it is to explicitly kill the process.

As I work on linux, the shell which starts plastic usually contains a line like "pkill -f -9 plastic && plastic" to forcefully restart it. If I would rip a single hair out each time it crashes, I would be bald.

On the other hand, it never crashed on me or anybody else in the team on windows.

Once again, I believe this is caused by Mono, as I know another tool with quite the same issues. Relying on .NET for a platform independent GUI driven tool seems to be a bad idea. Just a minute ago I had to swtich between four workspaces in order to create a label, and it crashed three times in the course of this.

merges are slow

Doing a trivial merge takes a long, long time, and I doubt that it is faster than svn would do it. This burns a lot of my time as I merge quite often.

Of course I wouldn't expect it to be anywhere near the performance of git or mercurial as the operation goes through the network. However, its slow even if the server is running locally.

You cannot create a new branch AND switch to it right away

For some reason, the dialog to create a new branch does not have a checkbox to simply switch to the branch that was just created. Instead, you will have to go to the cluttered 'branches' view and find the newly created one, or wait 5 minutes until the branch explorer shows it to you.

branches can never be deleted

If there is at least one changeset in a branch, you are not allowed to delete it any more. It seems like a bad joke that you are teased with a 'delete' entry in the branch's context menu, even though the operation will never succeed.

Even new branches which have no actual changeset cannot be deleted, as each branch in plastic must have a changeset in order to exist. This 'default' changeset is enough to prevent the delete operation to succeed.

This leads straight to the next issue.

branches are piling up

As branches cannot be deleted, their number will grow continuously, especially if you use feature and hotfix branches. This clutters up the 'branches' view, which is unfortunately needed to switch to newly created branches as the branch explorer display is delayed by a few minutes.

rename a branch which you are 'switched to'

Its very easy to rename a branch. Its so easy that one might be inclined to think it is a very safe operation which cannot do any harm. However, this is not the case as your workspace is in an invalid state once the branch you are currently on is renamed, either by yourself or by someone else. The next time you want to make a commit, you will see it fail as your workspace still tries to work with a branch of the old name.

Plastic fails to update your 'selector' to the changed name, but even if it would do it, everyone else using the renamed branch would still suffer from that problem.

by default, the branch explorer doesn't visually indicate which changeset/branch is checked out

By default, the only spot where you can see on which branch you are is the top-right of the gui, which is standard and rather small text. The only way to get a visual indication of the checked out branch is to add a 'conditional format' rule explicitly.

If one wants to see changeset that the working tree was checked out at, you are out of luck. This would be useful in case you want to see if your branch was advanced in the meanwhile.

default preferences check out everything read-only

If one doesn't change the preferences, the working tree will be read-only in its entirety. Its quite unexpected mainly because one is inclined to believe that locking/checkouts are not necessary if people are working on their own branches anyway.

For people who want to more fluently adjust their code and who don't want to bump their head on each file they want to change, this default setting is very annoying, initially.

default preferences enforce a check-in if files are added

The first time a new plastic user adds a file to the repository, which of course might be one of many more to come, plastic will show a generically looking dialog which prompts for a commit message. There is absolutely no relation to the add operation the user just performed, leaving him with three question marks above his head.

Users who just hit enter because they have no clue will create partial changeset which would not be usable by anyone checking it out, until they are finished adding-and-committing the remaining files.

The default setting facilitates changesets which are not usable.

checkin/checkout (i.e. file locking) is slow

When merging branches, there are easily dozens of files involved, even though they don't actually change relative to the two branches. This causes them to be checked out after the slow merge. When committing the files, plastic detects that there is no change, and allows to automatically undo the check-out of all of these items. This takes a while as each file will be handled individually, instead of all together.

cannot delete empty directory in the same changeset if you moved its content away

The way plastic works, it is unable to move all files out of a (now) empty directory, and delete that directory in the same changeset. This forces you to split the operation up into two changesets, which makes the operation non-atomic.

self merges

Assuming two workspaces A and B which are on the same branch and which edit the same file so that a manual merge is required. Branch B commits first, branch A comes in second. Plastic will detect that that working tree of the workspace is out of date and requires a merge with the latest version from the server, right in your changed working tree which is not yet committed ! Once the merge is done, you may commit.

Soon after you will notice a merge-destination arrow pointing from your newly created changeset onto itself, a self-merge. If you export this repository using the "cm fast-export ... ", the exported stream will be be invalid as self-merges are not supported by any importer, not even by Plastic 4 itself. Fortunately, one is able to fix the fast export files manually.

Another issue is that the merge is done prior to your commit. If you happen to accidentally destroy your file, the changes are gone for good as you didn't yet commit them.

Smaller Issues

• Edit Conflict Dialog: doesn't start at conflict, but at first possibly automatic merge. This is confusing and causes people to edit merges which could already be resolved.
  
• Edit Conflict Dialog: When editing a conflict, by default it adds the merge base as well, which makes only sense if you don't want to use either the left or the right side of the 3-way merge. This is the exception though.
  
• Edit Conflict Dialog: merge: if you have a file in two branches A and B and set the first line of file in A to "hello" and the first line of file in B to "world", make a commit in both and merge one into another, the Edit Conflict Dialog will display both lines underneath each other in separate lines if A and B are selected. Once the merge is done, you will find "helloworld" in one line, as it didn't add the newline that it previously showed in its merge result pane.
  
• Merge Dialog: requires more clicks than necessary when I want to "Merge All" as I have to confirm this choice in another popup. It can take a long time to search the merges.
  
• Merge Dialog and Edit Conflict Dialog: full branch names and file paths hard to read and too verbose, e.g. br:/main/some/feature@rep:reponame@reposerver:server:port .
  
• Create Branch Dialog: branch base selection is not saved, and always wrong in my case.
  
• Preferences Window is not resizable which forces me to scroll through the tabs.
  

All these issues I gathered during one day of work with plastic - most of the most annoying ones are hard to overlook, the other ones become over obvious if you stop a moment and think about it.

By now, even the greatest plastic advocate in our team as trouble backing Plastic SCMs performance, some find Plastic an impediment for their work.

Under normal circumstances, I might not care that much, but maybe I feel betrayed by all the nice advertisements and blog posts which made Plastic something that it simply is not: A good and usable SCM.

I expected too much, which probably is why I am so disappointed.

Sebastian

[dave]

Hi Sebastian,

thank you very much for your insightful analysis and feedback. We really appreciate it and for sure will use it to improve the product. Please find below my answers to your list; some of the things you describe have been solved / changed in version 4, some have a good story behind and some definitely need to be fixed.

branch explorer is about 5 minutes behind

If you create a branch for instance, you will not see this branch in the branch explorer. Instead, you have to go to the 'Branches' list, search the branch you just created within the 100 ones already there, and switch to it. All this of course is only necessary because there seems to be no way to say "create branch ... and switch to newly created branch".

The first time I ran into this I created a new branch and thought something was wrong as I didn't see it show up there. One of my first operations already caused plenty of confusion.

Uhm, this was reported long time ago, it was a problem related to timezones and it was fixed in version 3.0.187.6 long time ago, is your Plastic client version older than that?

Also, in the view options of the branch explorer, in the date filter, can you make sure that the "end date" check box is not checked and setting an old date?

GUIs are only production-ready on windows and instable on OSX and Linux

Once again, I believe this is caused by Mono, as I know another tool with quite the same issues. Relying on .NET for a platform independent GUI driven tool seems to be a bad idea. Just a minute ago I had to swtich between four workspaces in order to create a label, and it crashed three times in the course of this.

We'd love to help you solving this issue. If you want / can, we can setup a direct support session, connect to your machine and review it with you.

merges are slow

Doing a trivial merge takes a long, long time, and I doubt that it is faster than svn would do it. This burns a lot of my time as I merge quite often.

Of course I wouldn't expect it to be anywhere near the performance of git or mercurial as the operation goes through the network. However, its slow even if the server is running locally.

Merge speed has been much improved in version 4 but that said, I think the problem you face is that you are merging often from the /main branch to your feature branch (most likely to rebase it to the latest changes). This was a slower in version 3 than it is in version 4, since all the items in the branch are evaluated to check if they need to be merged.

In version 4, only the actual items that changed from one branch to the other are evaluated, greatly improving that scenario.

However, we usually suggest to use baselines on the mainline. Then, your branches start from well known and tested points (baselines, marked with a Plastic label). You don't need to rebase so often, since all tasks start from a well known point and a new baseline is created regularly integrating all the tasks to main in a controlled way and labeling. In this pattern (branch per task), merges usually happen from the task branches to the main branch, and only the items in the branch (short lived tasks) are evaluated. Speed is better in Plastic 3 using this pattern. Version 4 is actually pretty fast in any of them.

You cannot create a new branch AND switch to it right away

For some reason, the dialog to create a new branch does not have a checkbox to simply switch to the branch that was just created. Instead, you will have to go to the cluttered 'branches' view and find the newly created one, or wait 5 minutes until the branch explorer shows it to you.

The checkbox suggestion is really good, we'll get that implemented as soon as we can. Thanks for that!

The other thing is kind of weird, when you create a new branch, it is selected so you don't really have to look for it. Isn't this the case for you?

branches can never be deleted

If there is at least one changeset in a branch, you are not allowed to delete it any more. It seems like a bad joke that you are teased with a 'delete' entry in the branch's context menu, even though the operation will never succeed.

Even new branches which have no actual changeset cannot be deleted, as each branch in plastic must have a changeset in order to exist. This 'default' changeset is enough to prevent the delete operation to succeed.

The good news is that we fully implemented it in version 4 You can now delete the changesets and once the branch is empty, you can delete it.

In any case, you should be able to delete the branch if it's empty (meaning it only contains the creation changeset). If this is not the case, again, are you using the latest 3.0 version (3.0.187.31) ?

branches are piling up

As branches cannot be deleted, their number will grow continuously, especially if you use feature and hotfix branches. This clutters up the 'branches' view, which is unfortunately needed to switch to newly created branches as the branch explorer display is delayed by a few minutes.

ok, ok, I see your problem here. Have you tried the "filter" box on the top right of the branches view? that will help to quickly locate the branch. But anyway, the branch explorer problem was fixed in 3.0.187.6 unless we are missing something. Could you please confirm if it's happening to you on a newer version?

rename a branch which you are 'switched to'

Its very easy to rename a branch. Its so easy that one might be inclined to think it is a very safe operation which cannot do any harm. However, this is not the case as your workspace is in an invalid state once the branch you are currently on is renamed, either by yourself or by someone else. The next time you want to make a commit, you will see it fail as your workspace still tries to work with a branch of the old name.

Plastic fails to update your 'selector' to the changed name, but even if it would do it, everyone else using the renamed branch would still suffer from that problem.

Indeed, this is how it works, but... kindly, do you rename branches so often? If this is really a showstopper for you, we can really look into it, but we don't get this reported very often (happened a couple times, IIRC) and most of the time is the first couple of days when you are getting used to the tool and testing things... But again, I'm very interested to know if this is an scenario we need to support better.

by default, the branch explorer doesn't visually indicate which changeset/branch is checked out

By default, the only spot where you can see on which branch you are is the top-right of the gui, which is standard and rather small text. The only way to get a visual indication of the checked out branch is to add a 'conditional format' rule explicitly.

If one wants to see changeset that the working tree was checked out at, you are out of luck. This would be useful in case you want to see if your branch was advanced in the meanwhile.

Good news again, this is available in Plastic 4. Many people asked, we simply couldn't make everything in 3

default preferences check out everything read-only

If one doesn't change the preferences, the working tree will be read-only in its entirety. Its quite unexpected mainly because one is inclined to believe that locking/checkouts are not necessary if people are working on their own branches anyway.

For people who want to more fluently adjust their code and who don't want to bump their head on each file they want to change, this default setting is very annoying, initially.

You are totally right here and we are working to make "writable" the out-of-the-box behavior. It's only that some third party tools rely on that (anything using SCC integration, and that's a few IDEs). But it's definitely going to be out on a point release soon.

default preferences enforce a check-in if files are added

The first time a new plastic user adds a file to the repository, which of course might be one of many more to come, plastic will show a generically looking dialog which prompts for a commit message. There is absolutely no relation to the add operation the user just performed, leaving him with three question marks above his head.

Users who just hit enter because they have no clue will create partial changeset which would not be usable by anyone checking it out, until they are finished adding-and-committing the remaining files.

The default setting facilitates changesets which are not usable.

A good story here. Indeed what you describe was the default behavior in Plastic SCM 1.0 - 2.9. When we started designing the product, our idea was very clear that this was the right thing to do. And from 2006 to 2010 sooooooo many customers didn't get it and were asking to checkin directly, that finally we made it the default behavior in 3.0 (leaving it as a setting in case you want to change it).

I see, as you do, that not checking in added items should be the out of the box behavior, but... at the end of the day too many users were asking for the other option.

I continue answering in another post

[dave]

(Continued from the previous)

checkin/checkout (i.e. file locking) is slow

When merging branches, there are easily dozens of files involved, even though they don't actually change relative to the two branches. This causes them to be checked out after the slow merge. When committing the files, plastic detects that there is no change, and allows to automatically undo the check-out of all of these items. This takes a while as each file will be handled individually, instead of all together.

Undoing the checkout has been also improved a lot in 4. Still, If, more items than needed are detected by the merge, there may more things involved in your issue. Is it possible that the branches are loaded with items as the result of rebase operations, or that many items with same content were actually checked in instead of unchecked out after a merge?

cannot delete empty directory in the same changeset if you moved its content away

The way plastic works, it is unable to move all files out of a (now) empty directory, and delete that directory in the same

changeset. This forces you to split the operation up into two changesets, which makes the operation non-atomic.

I don't remember exactly about this case, but some border conditions like this have been reworked on 4, it's worth having a look at them there. We do our best to handle these cases.

[...]

By now, even the greatest plastic advocate in our team as trouble backing Plastic SCMs performance, some find Plastic an impediment for their work.

Under normal circumstances, I might not care that much, but maybe I feel betrayed by all the nice advertisements and blog posts which made Plastic something that it simply is not: A good and usable SCM.

I expected too much, which probably is why I am so disappointed.

Well, I can tell you that your comments will be definitely used to improve Plastic SCM and we really appreciate the time you dedicated to write them.

David

[Byron]

First of all, thanks for your elaborate reply. Even though I wanted to wait with my answers until everything is resolved for me, it might be better to catch up with this first.

Uhm, this was reported long time ago, it was a problem related to timezones and it was fixed in version 3.0.187.6 long time ago, is your Plastic client version older than that?

Also, in the view options of the branch explorer, in the date filter, can you make sure that the "end date" check box is not checked and setting an old date?

The "end date" check-box solved the issue for us. Besides I realized we had been on a rather old version, .22 if I remember correctly, which might have helped to make things worse.

We'd love to help you solving this issue. If you want / can, we can setup a direct support session, connect to your machine and review it with you.

Thank you ! Considering we are currently *trying* to move to plastic 4, having a direct support session might speed things up considerably. For me plastic3 most often crashed on linux when changing between workspaces. In the latest plastic 3 version, I couldn't easily recreate this issue. I have to say though that I am using the mono version of Plastic 4, as the one shipping with plastic 3.0.187.35 still seems not to have caught up with the one in plastic 4. However, I believe that mono is critical in how stable plastic is, considering that plastic 3 almost never crashes on windows.

The checkbox suggestion is really good, we'll get that implemented as soon as we can. Thanks for that!

The other thing is kind of weird, when you create a new branch, it is selected so you don't really have to look for it. Isn't this the case for you?

The newly created branch not showing up in the branch explorer was related to the "end date" issue, which is now solved. Now I can happily create new branches, and the "and switch to new branch" option is not that important anymore as I can just click it in the branch explorer now. However, having such a checkbox would probably be good anyway, as it brings you closer to the very common "git checkout -b newBranch".

The good news is that we fully implemented it in version 4 You can now delete the changesets and once the branch is empty, you can delete it.

In any case, you should be able to delete the branch if it's empty (meaning it only contains the creation changeset). If this is not the case, again, are you using the latest 3.0 version (3.0.187.31) ?

This works now, as we switched to version 3. ... .32 in production.

Indeed, this is how it works, but... kindly, do you rename branches so often? If this is really a showstopper for you, we can really look into it, but we don't get this reported very often (happened a couple times, IIRC) and most of the time is the first couple of days when you are getting used to the tool and testing things... But again, I'm very interested to know if this is an scenario we need to support better.

Even though it doesn't happen that often, it happens. My workaround is to assure I am not switched to a branch I want to rename, yet it doesn't help anybody who still has it checked out. Considering that you keep branches around forever (in the normal case), it might be better not to identify them by their easily changeable name. Or maybe make it more obvious that renaming it is an operation with consequences.

Maybe, what hurts the user most, is to get errors telling him that his (now renamed) branch doesn't exist. Perhaps the gui can provide better error messages, or, as a start, update the selector for the one who does the renaming.

Lets compare with git: git br -m newName will rename your current branch to the given name. It actually manages to setup your HEAD to point to the newly named branch. This is what one should be able to expect.

Undoing the checkout has been also improved a lot in 4. Still, If, more items than needed are detected by the merge, there may more things involved in your issue. Is it possible that the branches are loaded with items as the result of rebase operations, or that many items with same content were actually checked in instead of unchecked out after a merge?

We don't use rebasing, and as far as I could (and can) see, the performance penalty originated from the undo-checkout operation. However, for plastic 3 it doesn't matter for me anymore, as we hope to be on plastic 4 soon.

Thanks for the support,

Sebastian

[manu]

Hello Sebastian, thank you again for your feedback, we really appreciate it.

The "end date" check-box solved the issue for us. Besides I realized we had been on a rather old version, .22 if I remember correctly, which might have helped to make things worse.

Cool, it's great to know everything is fine.

Thank you ! Considering we are currently *trying* to move to plastic 4, having a direct support session might speed things up considerably. For me plastic3 most often crashed on linux when changing between workspaces. In the latest plastic 3 version, I couldn't easily recreate this issue. I have to say though that I am using the mono version of Plastic 4, as the one shipping with plastic 3.0.187.35 still seems not to have caught up with the one in plastic 4. However, I believe that mono is critical in how stable plastic is, considering that plastic 3 almost never crashes on windows.

Yes, you are completely right, we rely on Mono under UNIX systems BUT I have to tell you we have been optimizing our code to avoid this "incompatibilities", the PlasticSCM 4.0 is much UNIX ready than 3.0. Hopefully, in 4.0, you will not see crashes again.

The newly created branch not showing up in the branch explorer was related to the "end date" issue, which is now solved. Now I can happily create new branches, and the "and switch to new branch" option is not that important anymore as I can just click it in the branch explorer now. However, having such a checkbox would probably be good anyway, as it brings you closer to the very common "git checkout -b newBranch".

You will never guess what; we have the checkbox in the last release!

This works now, as we switched to version 3. ... .32 in production.

Even though it doesn't happen that often, it happens. My workaround is to assure I am not switched to a branch I want to rename, yet it doesn't help anybody who still has it checked out. Considering that you keep branches around forever (in the normal case), it might be better not to identify them by their easily changeable name. Or maybe make it more obvious that renaming it is an operation with consequences.

Maybe, what hurts the user most, is to get errors telling him that his (now renamed) branch doesn't exist. Perhaps the gui can provide better error messages, or, as a start, update the selector for the one who does the renaming.

Lets compare with git: git br -m newName will rename your current branch to the given name. It actually manages to setup your HEAD to point to the newly named branch. This is what one should be able to expect.

Yes, this is a pending topic frequently asked, we have to improve this scenario.

We don't use rebasing, and as far as I could (and can) see, the performance penalty originated from the undo-checkout operation. However, for plastic 3 it doesn't matter for me anymore, as we hope to be on plastic 4 soon.

I would like to see you moving to 4.0! I think you will notice the difference! Please feel free to ask if you have questions about how to do it.

Regards,

Manu.