General questions about PlasticSCM and migration from SVN

[slurdge]

Hi,

I post this in general since some questions are related to migration but not all .

We are evaluating the process to migrate toward PlasticSCM. SVN is great, but has some limitations and the workflow could be much more easy with PlasticSCM in our view. We also use Perforce in another context, but it has also its shortcomings (price being one of them).

So here is my batch of questions. If they are already answered elsewhere, I'm sorry, I looked through the forums and did not found them.

Performance: This is of utmost importance for us. For many reasons, we have a tendendy to put a large amount in the SCM. In our philosophy, the bootstrap is only the SCM, else everything is self contained. This means SDKs, data, etc... is on the server. This is where SVN is weak. We have two performances issues:

- Big files: How does PlasticSCM handle very large files ? Is there a possibility to reduce the history for theses files (removing very old versions for examples). Also, does the diff algorithm change (or can be discarded entirely).

- Numerous files: This is a very large set of small files, like 30K+ files. What would be the impact on plasticSCM ? With SVN, there can be as much as 2-3 minutes of lags under certain conditions.

Integration:

- Trac integration. We use Trac a lot. I understand that some integration is already there, namely, the changeset/task integration (makes sense since this is where you are strong). However, I did not find any docs on theses:

* Changeset display : Can we see the changesets in Trac ? Is it possible ? Trac does support now different SCM backends, I could try to interface it if it were not too complicated. We use it a lot to review changes.

* Source display : This is less important for us, but always nice to have. It allows to link source to docs, etc...

- Email integration. Can we use a hook to send an email with the diffed files each time a commit is done ? A bit like svnmailer.

Python/C++/C# integration:

- Perforce provides a nice client code skeleton and python bindings that allows us to have tools that do direct commits/checkouts/diffs etc... Do you have something similar or plans to have it? Perforce has also a "special" mode in command line where it returns a python dictionary with the results. This is less desirable, but can do the work (we used it in the past). Also, a clean dll with nice exports can do it (all major languages will allow its import quite easily). This is quite important, because writing tools that parse the stdout is not very robust (and tedious).

Misc:

- Shelves. I believe that there are not needed and can be achieved with the current workflow, am I right ?

- SVN import. Is the SVN import a "one time" operation or can it be incremental ? This is just a timing issue, and not so important.

Well, this is all I can think of for now. If you need any more precision, I would be happy to provide it. Moreover, let me say that the Community Edition is a great idea, this is perfect for us that are (for now, let's hope) tight on budget. I really appreciated the philosophy of PlasticSCM, and wanted to try it.

[miller]

Hi Slurdge,

Ill answer some of your questions, hopefully all of them.

Regarding performance, Plastic SCM is one of the fastest out there!

Big files.. hmmm,, no problem at all, we have some gaming developers with GIGA bytes of files and very big binaries,

and other customers with many kilos of files, I would not have much concern about the performance.

Trac integrates well with Plastic SCM see the Extension manual for details:

http://www.plasticscm.com/releases/3.0.1/manuals-html/en/extensionsguide.htm

Sending a mail upon a comit can be acheived with triggers, you can scrip any kind of activity with triggers.

SVN AND Perforce import can be incremental, so yes, you can work and import until you get all your code into

Plastic.

Regards,

Miller

[slurdge]

Hi Miller and thank you for your answers.

It seems that indeed PlasticSCM can meet most of our needs (performance is _really_ important).

I've read the Extension manual and to me it seems that it focuses on tasks and bugs.

However we need also integration with tools and/or trac's diff view (for an example see http://trac.edgewall.org/changeset/10340 ). I could write this part if needed, but see my second point .

Integration with tools is not on our priority list yet, but planning ahead is always cool. Is there any way to have an interface to PlasticSCM client that is not the cli ?

If the cli is the only way, is there any way to have structured output from it ?

E.g.

cm --output=tool ci <file>

which would produce structured output.

I'll try to see the output of different commands later.

Regards,

Aur

[jimmy2pinz]

Hello,

I want to thank you for your interest in Plastic SCM. Let me take a stab at your new questions.

>>It seems that indeed PlasticSCM can meet most of our needs (performance is _really_ important).

<james> we spend a lot of time constantly improving overall performance. If you haven't seen this yet, please take a few minute to review: http://codicesoftware.blogspot.com/search/label/scalability Both P4 and SVN were compared against with Plastic.

>>I've read the Extension manual and to me it seems that it focuses on tasks and bugs.

<james> That's probably a fair statement. We are working on improving all our documentation. We are very focused on Branch per Task (task based development) and that may be why there's is less focus on some of the other things you have inquired about.

>>However we need also integration with tools and/or trac's diff view (for an example see http://trac.edgewall.org/changeset/10340 ). I could write this part if needed, but see my second point .

<james> This would be very powerful indeed. I don't think it would be difficult, but it probably stems from a lack of customer demand right now to build this level of integration. We'll certainly give it serious thought and consideration.

>>Integration with tools is not on our priority list yet, but planning ahead is always cool. Is there any way to have an >>interface to PlasticSCM client that is not the cli ? If the cli is the only way, is there any way to have structured output >>from it ?

<james> currently, yes. We are working on an API and I think this would give you the flexibility you're looking for. With that said, we feel you should be able to do a lot from the CLI. It's very full in terms of capability.

One question for you, if you don't mind? Could you take a few minutes and expand on the shortcomings for both Perforce and SVN as you currently see them? I'm sure I can make good assumptions, but it would be great to hear your own experiences and opinions if you don't mind sharing them.

Thank you,

James

[slurdge]

One question for you, if you don't mind? Could you take a few minutes and expand on the shortcomings for both Perforce and SVN as you currently see them? I'm sure I can make good assumptions, but it would be great to hear your own experiences and opinions if you don't mind sharing them.

Not at all. Please keep in mind this is just an opinion from my use, I may be very wrong and miss a point, but I've used both quite a bit. If some people would like to correct me on some points, please do so .

Let's start with subversion. Subversion has two great strengths in my opinion. One being open source, second one being here for a good amount of time. This gives you a whole load of interoperability. But the client/server model is outdated, the .svn folders are just nightmarish (this is fixed in svn1.7 due in the end of the year, along with some performance enhancements). .svn folders alone introduces so much lag that is painful. Also, so some reasons, a very good free GUI has not appeared. Sure, there is TortoiseSVN that does it, but this is a bit tedious if you diverge from basic operations. Also, some people do not like the explorer integration (it can slow down the whole explorer). Operation on many small files are often slow. Also, things like shelves etc... are not that easy. SVN was and still is a very good centralized system, but it need a refresh (let see what svn1.7 and 1.8 brings down).

I've also used Perforce quite a bit. I've also written tools that interact with it and extensions (a changelist validation program being one of them, the other one expanded a shelve script available into a full fledged shelve extension before it was included in Perforce's software).

Perforce is very good at what it does. However it costs quite a bit (more than PlasticSCM if I'm not mistaken). Second point is server administration that is far from trivial. The new client is excellent, however it can hang on heavy operations. Also, the branching methodology is a bit old, and therefore if you create a lot of branches, you can be overwhelmed (shelves are in fact microbranches in perforce - I suppose this is the same thing in PlasticSCM). The fact that it insists on a checkout on every file by putting them in readonly is tedious. This basically mean that you must write a extension for every main program you use (Visual, Notepad++, etc...). The "resolve offline work" is at best a patch on it. This is a good thing in some occasion, but also a very bad thing in others (for example in continuous integration process, the readonly flag is just cumbersome, but a allwrite flag can be specified). However its client interface exposition is one of the best I've seen. From python to ruby, everything seems to be supported.

However, its centralized system can be very inconvenient. If you are with two computers and a remote drive, setting things up without screwing your view of the workspace can be tricky. Since the server "knows" what is/should be on your hard drive, you expose yourself to serious trouble if you mess with that. With technical people this is often not a problem, however, in the videogame industry, where Perforce is used a lot, there are many non technical persons that struggle with that.

To conclude on Perforce, I suppose it would have much more user base with a different pricing, but this is their decision. Basically they are saying "no" to small teams and open source.

I guess that some of the shortcomings of Perforce and SVN could apply to plastic as well, but I'm convinced from what I read from your documentation and technical papers that you are headed in the right direction.

If you are interested in feedback, I could get back to you once I tried some serious work with Plastic.

Regards,

Aur

[jimmy2pinz]

Aur