Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

SCM trends at DDJ

Tuesday, April 29, 2008 Pablo Santos 0 Comments

The folks at DDJ have just interviewed me about SCM Trends.
I tried to give my own view about the future of SCM and even talked about how threading and concurrency (which I've to admit is one of my favourite topics since long, long ago I first read Ben Ari's book, now there's a new edition available and also the superb Jeffrey Richter's book which is also renewed this year) have an impact in the version control field, or even better how I believe SCM can help there.
I've also focused on why C# was an important decision in the early Plastic development, and more specifically why Mono was actually the key which really opened the C# door for us!
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios:

Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

The break up, a Clearcase bad love affair

Wednesday, April 09, 2008 Pablo Santos 0 Comments

This is the true story of a break up: a sesioned SCM manager tells us why he finally broke up with is beloved system: clearcase.

It probably sounds just like a funny joke, but please read on carefully and find the hard facts behind his disappointment...

Here it goes:

After 12 years working and playing with clearcase I'm fed up with it.
The beautiful lady I fell in love with after my first months in a software development and R&D company became a real pain for me. And a new mother in law, IBM, didn't make it any better.

At the time we met we were doing development for digital media on these nice systems made by Silicon graphics.
It was the time when a system at work was way more powerful, and much more expensive, compared to the silly 486 PC running some version of DOS I had at home. So I went to work with the idea that what I did really mattered for me and the company. After all it was before the bubble.

What I particularly liked about clearcase was the fact that it was completely invisible for the developer.



You set a view and you could start working with any tool you wanted, the sources were right there where you needed them. It was a fast and advanced environment. It had directory versioning, so you could change the structure of your code without trouble. You had advanced branching and merging, you had merge tracking and the branching strategy we used at the time was branching per task. It was possible to do this efficiently in clearcase since it was so good at branching and merging.

And it had all this 12 years ago!

And the stunning fact is that while the world evolves, clearcase chooses the completely wrong direction.

It tried with the ugliest implementation ever conceived for a SCM environment, UCM, Unified Change Management, trying to impose a ridiculous overloaded process on top of the old base. She completely ignored her old lover boy, the developer, while trying to impress those people who hated development. It broke down the whole idea of branching per task.


It gave up on having a consistent user interface on all the platforms it supports, using clearcase on the different flavors of UNIX, Microsoft windows or Linux really is a different thing. The clearcase GUI on UNIX and Linux is really bad. And why has the command line so much more features compared with the GUI? And why is Apple ignored?

The fact that there is no standard way of doing a recursive check-out or check-in, the error messages that seem to be completely unrelated with the real error, the fact that if line endings are changed in textfiles used in a crossplatform environment and the merge and compare tools that fail on these, the fact that the number of characters on a line, e.g. in an XML file is limited and makes the merger fail are all things I could handle.

But the real showstopper comes with the integrations provided to 3rd party tool like eclipse, WSAD, Visual studio etc... , these integrations are in fact only integrations to do a check-in/check-out, all other clearcase operations are a pain in these environments. Simply switching views in an IDE to a view on another branch in the same project is almost impossible, effectively making the entire branching power useless.

While at the old days, clearcase was invisible for the developer, a silent and helpful companion, nowadays it makes a developer's work difficult, slow and cumbersome. Some people even argue that going back to the stoneage of SCM practice, by using tools like CVS or Subversion, is better then using clearcase.

And right at the time when I really needed to feel young again, fresh and excited about software development, a beautiful, open product appeared on the scene, made by developers for developers, all the focus is again on how development and integration can be done in an efficient, fast and powerful way. With a consistent look-and-feel on all the platforms it supports. (it even runs on Apple, a brand ClearCase always ignored), with an easy to use branching and merging environment, with good integrations with your IDE, so switching workspaces to another branch is a very easy and fast task, with merge tracking and correct directory versioning.
In fact with all the good things of clearcase and a solution for most problems it has.

Please go and check-out plastic SCM 2.0 as fast as you can, you won't be disappointed.
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios:

Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

The fastest way to insert 100K records

Tuesday, April 08, 2008 Pablo Santos 14 Comments

I’m doing some performance tests today with our three different database backends: MySql, Firebird and SQL Server.

My goal is to find the fastest way to insert a big number of records into a table taking into account the different backends.

Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

14 comentarios:

Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Obtaining reports about repository activity

Thursday, April 03, 2008 Pablo Santos 0 Comments

What if you want to know which revisions have been created in the last days? Who made the changes, where? Or if you're looking for changes made at a certain component to locate an specific modification you'd like to review?

It is very easy now with the customizable views in Plastic 2.0.

Take a look at the following figure (click to enlarge):



I've customized the changeset view to actually display revisions. And I'm using the query system to retrieve the revisions I've created since April 1th at our main repository.

I'm then using the filter box to focus on the revisions at the directory 01nerva

The query is very simple:

find revisions where date >= '4/1/2008' and owner = 'pablo' on repository 'codice'

Of course I could go even further and try to focus on the revisions created on a given branch, or bigger than a certain changeset... and so on.

The following query will locate the revisions created at two repositories after a given date on a branch different than the main one.

find revisions where date >= '4/1/2008' and owner = 'pablo' and branch != '/main' on repositories 'codice','pnunit'

As you see, the query system is very useful to create activity reports, locate certain changes, inspect modifications and so on.

Hope it helps!
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

0 comentarios:

Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Integration strategies

Wednesday, April 02, 2008 Pablo Santos 1 Comments

Previously we were discussing about the future of continuous integration, according to Duvall’s award-winning book and possible alternatives.

Today I’ll be focusing precisely on this topic: different alternatives to handle the integration phase.

Some will prefer to stick with the main-line development style, while others will gravitate through a more controlled (and maybe less agile if we go religious) approach.

Beyond the selected branching strategy, there will be also an integration strategy.

Let’s start with main-line development. This is probably the most well-known and spread technique in version control. How does it work? Simple, all check-ins go to the main branch, as you can see in the following figure:

Of course it has its own advantages and disadvantages.

Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

1 comentarios: