Why choose Plastic SCM?

[jspraul]

I was recently in the position to choose a (free) source control solution for a (microscopic) client, and I chose Perforce. I actually was hoping to go with Plastic SCM to gain experience working with a distributed source control solution, but simply couldn't justify using it in comparison. When all else is stripped away, Perforce has years more experience.

Also, I happened to see mentioned in passing in a Plastic SCM blog post the database-level incompatibilities between v3 and 4. You shouldn't mention this so briefly without taking great pains to explain how this process is a 100% smooth transition for your users. Even the slightest perception of a cavalier attitude in this department is going to turn people off.

Source code is the heart of what I do; I'm not sure the best way Plastic SCM can convince super-small-scale developers like me that you have anything to offer. The emphasis on speed gets me nowhere.

I hope sharing my perspective is useful to the developers of Plastic SCM; I'm not trying to start any religious flame wars here... this is just my perception of reality. I do use the diff/merge tool as the moved code detection is awesome (though it doesn't seem too smart about how whitespace affects code, I can live with that).

[CodingGorilla]

Well, if I can chime in: If you've never used Plastic before (so you don't have any existing 3.0 repositories) I'm not sure why the conversion process would be a turn off to you. I do believe it's also been mentioned that Plastic has never made this sort of change before, but the new features in 4.0 justified the upgrade. So I wouldn't call it a "cavalier" change.

I guess it really depends on your scenario, for me the distributed model is very nice, as I work both at home and in the office. And using the DVCS model is very advantageous; and for my employer the fact that OTHER projects can still use the central server model is very nice (we have other developers that are stuck on this model). So that flexibility is very nice. As you also mentioned, the speed is a very nice feature (for me). The fact that I can commit literally 20MB of changes in a few seconds (even across WAN connections) is a god send. Where svn commits could take 5+ minutes, Plastic can commit in under a minute.

And, the merging and branching is unmatched (IMHO). But as you said, if these features are not important to you, then I guess you can legitimately say that Plastic has nothing to offer you. But if a VCS can offer you these features, even though you don't need them right now, why wouldn't you choose it? Times change, your work patterns will likely change, so why not have a VCS that can change with you? That just seems a little short sighted to me.

Also, I'm not trying to argue with you, I'm offering my opinion as something for you to consider. As always, it's just my opinion and everyone's entited to it.

[manu]

Hi!

I was recently in the position to choose a (free) source control solution for a (microscopic) client.

(To be free) It has to be very very microscopic (Perforce pricing page: http://www.perforce.com/purchase#)

Users 1-20

$740 per user (Per User License Fee)

$900 per user (Per User License Fee + Standard Support ($160 per user))

I think that some time ago it was free for 2 users or if it was for students, I'm not sure if now it's the same.

Also, I happened to see mentioned in passing in a Plastic SCM blog post the database-level incompatibilities between v3 and 4. You shouldn't mention this so briefly without taking great pains to explain how this process is a 100% smooth transition for your users. Even the slightest perception of a cavalier attitude in this department is going to turn people off.

But they are actually not compatible, I'm sorry but we can't lie...

Users will be able to migrate the databases in a very easy way... we will publish it soon.

Anyway, if you are a new user you can start using 4.0 and get rid of the migration.... as CodingGorilla said....

Source code is the heart of what I do; I'm not sure the best way Plastic SCM can convince super-small-scale developers like me that you have anything to offer. The emphasis on speed gets me nowhere.

CodingGorilla said it pretty good.

We are faster, we can create branches much better, we can merge much better, we are fully distributed, you can work centralized too, the GUI is from another world compared with p4, you can choose your favorite bakend, the system usage is easier, we have the XMerge, we have the Xlinks.....

I don't know, I'm sure that there are more.... we can prepare a blog post about it if you want.

[carpediemevive]

I was in the exact same position as the original poster and I looked at Perforce expecting to choose that one, and I was completely turned off by it. While Perforce might have so much history to be almost considered a standard of source control, I found their product lack-luster and really sub-par for what they charged.

Keeping source control safe is really the easiest part of what these products do, and I didn't find much difference when comparing the two products. They both offer ways to keep your source safe and to allow you to work with it in a very flexible manner. So for me, it was about the ancillary ease-of-use type features that put Plastic light-years ahead of Perforce for me.

First off, I live in an almost exclusively visual studio world. Plastic's Visual Studio integration is the best, perhaps second only to Microsoft's Team Server. Plastic does it such an easy way to, they just make all the views in the GUI modular and allow you to bring each one into Visual Studio as you want. This also means Plastic was the only one that allowed me to have a visual clue to constantly remind me of what branch I'm in. This is similar to the GIT feature that shows you your working branch on the command line, except I see it inside my IDE where I prefer to do all my work.

Second, I also lived in an exclusively Windows world. Plastic comes out of the box with built-in ActiveDirectory support. To get the kind of access control I wanted in Perforce I would have to work with authentication scripts that tied into the LDAP interface for ActiveDirectory. I write code for work, I try very hard not to write code so I can write code. The concept of having a whole secondary set of scripts to just get the product in a "working" state for me was a very big turn-off. Since Plastic gave it to me out of the box, I didn't see any reason not to use it instead.

Third, the UI! If you've seen Plastic 4 I don't know how or why you would ever want to use Perforce's UI to do anything. I found the whole thing entirely too confusing and built to be hard to use. Plastic 3 was better than Perforce in this regard, but Plastic 4 makes Perforce look like something I wrote fresh out of college.

I know you've already made your mind up, and I'm not looking to convince you, but for people out there in the same position as you and I, maybe they can read my list as to why I choose Plastic instead.

[CodingGorilla]

This also means Plastic was the only one that allowed me to have a visual clue to constantly remind me of what branch I'm in. This is similar to the GIT feature that shows you your working branch on the command line, except I see it inside my IDE where I prefer to do all my work.

Wait, where's this? I know in the Plastic GUI you can see this, but you can see it in Visual Studio too? That's a cool feature, show me where!

[carpediemevive]

View -> Plastic SCM -> Show Workspace Working Info is the option, and it shows me my workspace location, current repository, branch, and label. It was (and I'm not kidding) one of the reasons I chose Plastic as funny as that sounds.

I was in a position where I was going to try to convince my co-workers to branch a lot more than we do now (which is never), but we were coming from a CVS world where it's such a task to branch and merge. This contextual awareness is so great because it kills the excuse of not knowing what branch you are working in.

[CodingGorilla]

Awesome! I've never even seen that menu before, all the commands (which I thought weren't available inside of Visual Studio) are there. Learn something new everyday.

Yea, I feel your pain on the branching, I'm fighting the same battles with my co-workers as well. It's difficult to explain to them why they should do different tasks in different branchs when "this is how we've always done it." Luckily, on one project in particular we've had some mishaps where changes that were not approved were moved from a beta to a production because they were doing all the changes in one spot and they lost track of what was what. That made my point for me.

[carpediemevive]

I'm really hoping to get the speed of development to increase. Currently we have just one programmer work on one project at a time. Some projects are just getting too big, and we could all benefit from being able to work actually together instead of side by side. Merges are so much more convenient in that regard I think. It's a slow and painful process to convince other people though!

[jspraul]

(To be free) It has to be very very microscopic (Perforce pricing page: http://www.perforce.com/purchase#)

Users 1-20

$740 per user (Per User License Fee)

$900 per user (Per User License Fee + Standard Support ($160 per user))

I think that some time ago it was free for 2 users or if it was for students, I'm not sure if now it's the same.

Perforce is still free for 2 users.

But they are actually not compatible, I'm sorry but we can't lie...

Users will be able to migrate the databases in a very easy way... we will publish it soon.

Anyway, if you are a new user you can start using 4.0 and get rid of the migration.... as CodingGorilla said....

The problem is not that the versions are not compatible; such is the price of progress. The problem is glossing over the migration process. I am not asking you to hide anything; in fact it's best to make these things very clear. What I am pointing out is that these types of changes immediately raise eyebrows so your cause is best served by preparing the explanation of the transition process beforehand so I can evaluate for myself whether or not the process is straightforward. The only thing I have heard about any of this is mentioned in passing in one blog post: "since Plastic SCM 4.0 uses a different database schema that is not directly upgradeable". I refuse to believe such a change will never happen again, and I want to know that PlasticSCM cares deeply about source code imported from older versions of their own product, not to mention code coming from another source control system!

CodingGorilla said it pretty good.

We are faster, we can create branches much better, we can merge much better, we are fully distributed, you can work centralized too, the GUI is from another world compared with p4, you can choose your favorite bakend, the system usage is easier, we have the XMerge, we have the Xlinks.....

I don't know, I'm sure that there are more.... we can prepare a blog post about it if you want.

User carpediemevive did a better job selling me on PlasticSCM vs Perforce... you should write up some talking points and post a video interview with a transcription if this person is willing! I have to show non-technical people how to work with source control so the user-friendly GUI and Visual Studio integration might be enough to convince me to switch... I will definitely have to check it out now.

[jspraul]

Well, if I can chime in: If you've never used Plastic before (so you don't have any existing 3.0 repositories) I'm not sure why the conversion process would be a turn off to you. I do believe it's also been mentioned that Plastic has never made this sort of change before, but the new features in 4.0 justified the upgrade. So I wouldn't call it a "cavalier" change.

I didn't mean the change was cavalier, I meant any communication on how the change will actually impact users is completely missing. This sets a bad precedent for me for future changes even though I don't have to deal specifically with this one.

I guess it really depends on your scenario, for me the distributed model is very nice, as I work both at home and in the office. And using the DVCS model is very advantageous; and for my employer the fact that OTHER projects can still use the central server model is very nice (we have other developers that are stuck on this model). So that flexibility is very nice. As you also mentioned, the speed is a very nice feature (for me). The fact that I can commit literally 20MB of changes in a few seconds (even across WAN connections) is a god send. Where svn commits could take 5+ minutes, Plastic can commit in under a minute.

And, the merging and branching is unmatched (IMHO). But as you said, if these features are not important to you, then I guess you can legitimately say that Plastic has nothing to offer you. But if a VCS can offer you these features, even though you don't need them right now, why wouldn't you choose it? Times change, your work patterns will likely change, so why not have a VCS that can change with you? That just seems a little short sighted to me.

Also, I'm not trying to argue with you, I'm offering my opinion as something for you to consider. As always, it's just my opinion and everyone's entited to it.

Thanks for your input. Everything you have mentioned would push me towards Git as a DVCS with more widespread usage rather than PlasticSCM. (Well, the central repository model not quite but still do-able with Git.) The reason PlasticSCM gets my interest is the convenience of Windows-specific support as user carpediemevive shared has made his decision easy.

[jspraul]

I was in the exact same position as the original poster and I looked at Perforce expecting to choose that one, and I was completely turned off by it. While Perforce might have so much history to be almost considered a standard of source control, I found their product lack-luster and really sub-par for what they charged.

Keeping source control safe is really the easiest part of what these products do, and I didn't find much difference when comparing the two products. They both offer ways to keep your source safe and to allow you to work with it in a very flexible manner. So for me, it was about the ancillary ease-of-use type features that put Plastic light-years ahead of Perforce for me.

Thank you for taking the time to share this information with me. Since I had no experience working with Perforce or PlasticSCM but had narrowed my options down to them since they are the commercially supported options offering limited free versions, all I could go on was the 'work experience' of the two choices. Perforce used to advertise their speed, but as more options become available there will always be something faster (Git, PlasticSCM, etc.).

Emphasizing speed, merging, etc. doesn't affect me much as a free user. (I should take the distant future into consideration; I'd prefer to do this by evaluating how well supported source control import migration processes already are so that I can change my mind any time in the future...).

I chose Perforce because they've seen the edge cases PlasticSCM has not and perhaps never will (PDF). I was disappointed in some ways to see Perforce's custom backend, but I expect Perforce to handle the related issues. PlasticSCM kind of punts in this department (and perhaps rightly so), forcing users to become expert database troubleshooters and maintainers when faced with edge cases. (Pointing to each database's community as a solution for someone's source control issue is kind of a turn-off.) Of course, these issues occur less frequently over time...

To me it is telling that a search for 'plasticscm database corruption' brings up top results of forum postings and 'we use awesome database' sales pages, while a search for 'perforce database corruption' pulls up perforce documentation and knowledge base articles. To me this means Perforce is out there actively explaining how to plan for the inevitable hardware failure or software bug; I suppose this could also be interpreted positively for PlasticSCM ('no problems, ever!' comes up).

First off, I live in an almost exclusively visual studio world. Plastic's Visual Studio integration is the best, perhaps second only to Microsoft's Team Server. Plastic does it such an easy way to, they just make all the views in the GUI modular and allow you to bring each one into Visual Studio as you want. This also means Plastic was the only one that allowed me to have a visual clue to constantly remind me of what branch I'm in. This is similar to the GIT feature that shows you your working branch on the command line, except I see it inside my IDE where I prefer to do all my work.

Second, I also lived in an exclusively Windows world. Plastic comes out of the box with built-in ActiveDirectory support. To get the kind of access control I wanted in Perforce I would have to work with authentication scripts that tied into the LDAP interface for ActiveDirectory. I write code for work, I try very hard not to write code so I can write code. The concept of having a whole secondary set of scripts to just get the product in a "working" state for me was a very big turn-off. Since Plastic gave it to me out of the box, I didn't see any reason not to use it instead.

Third, the UI! If you've seen Plastic 4 I don't know how or why you would ever want to use Perforce's UI to do anything. I found the whole thing entirely too confusing and built to be hard to use. Plastic 3 was better than Perforce in this regard, but Plastic 4 makes Perforce look like something I wrote fresh out of college.

I know you've already made your mind up, and I'm not looking to convince you, but for people out there in the same position as you and I, maybe they can read my list as to why I choose Plastic instead.

This information is causing me to evaluate the Plastic GUI. The software being easy to use will help in the task of convincing non-technical web designers to even use source control at all! (Yes, this configuration is that tiny.)

Thanks to all for input and I appreciate being able to share my thoughts without feeling attacked. : )

[carpediemevive]

No problem; I'm just happy for the discussion. I wouldn't consider myself an expert in the area, but I think that your criticisms against Plastic SCM are fair ones for you to be concerned about. If you were to ask me which I think had more exposure and probably a more mature product, my gut reaction would probably be Perforce.

After having played around with Plastic (especially 4) I'm pretty comfortable with their database solution. In the Plastic 3 days, firebird (I believe) was the default data store, and while it wasn't bad, I was hesitant to use a database I am so not familiar with. Plastic 4 pushes you to pick a data storage solution that meets your needs which is really fantastic, and makes me feel a lot more comfortable when it comes to disaster recovery and things of that nature.

All the reasons I listed for why I chose Plastic are (obviously) custom tailored for me and my needs, so I wouldn't expect them to work for everyone. I was in a position where I was the only one who wanted to move away from the current solution (CVS *yikes*) so I really wanted to make sure whatever solution I provided as an alternative was sleek and snazzy as well as functional.

Good luck and definitely let us know how it turns out!

[psantosl]

@jspraul thanks for all the insights, it definitely helps making a better product.

Look, as I explained 4.0 is the first release where we've broken database compatibility. Plastic server was always (5 years) able to upgrade to newest version, but we decided to change it (first time ever) for 4.0. There are several reasons that I've already mentioned before.

Regarding the "explanation": we've a pretty strong relationship with our user base, so we decided to move first the "newcomers" to 4.0 (jump to 4.0) while the people on 3.0 would continue for some time with the old release. They're willing to move but not in a hurry, and we're doing our best to support them all on a daily basis. But, getting new people aboard is important, that's why (probably mistakenly, but we've to make choices) we decided to publish 4.0 before having a clear 3.0-4.0 migration path (clearly explained).

Regarding your comparison against p4: p4 is *definitely* an exceptional product, and they don't need me to say that at all, of course. That being said: our biggest success is coming from big teams replacing Perforce and ClearCase. Perforce merge, distributed development, branching and even scalability (yes, google made a big effort to make it run... simply, you do not need all these with plastic) is simply behind Plastic.

The points about the "edge cases" related to databases: as you mentioned, they're really, really, corner cases: thousands of users on Fb are not experiencing any of these problems, at all. It is really,really, really rare for us to experience database corruption, in fact, it never happened to us except on rare cases when a Firebird Embedded database runs on a disk that runs out of space... which used to be a Fb bug... Honestly, it didn't happen more often than the posts you've found, that's why it is maybe hard to find, because it is hard to reproduce in real life. 'plasticscm database corruption' is probably not the best term for the case, anyway

But, as you know, there's a product lifecycle defined out there: with "early adopters" eager to jump into new stuff and "conservatives" who will only move after 10 years... Plastic, today, is for early adopters, for people willing to trade maturity for edge functionality on certain areas.

And of course, day after day, week after week, plastic gets even more edge features and gets more and more mature...

Thanks all for your support and all the best for 2012

[jspraul]

But, as you know, there's a product lifecycle defined out there: with "early adopters" eager to jump into new stuff and "conservatives" who will only move after 10 years... Plastic, today, is for early adopters, for people willing to trade maturity for edge functionality on certain areas.

And of course, day after day, week after week, plastic gets even more edge features and gets more and more mature...

Thanks all for your support and all the best for 2012

Thank you for your time and the same to you in the new year.