Release early, release often - 3.0.1 is out!

Friday, July 30, 2010 Pablo Santos news 0 Comments

We read about how google is going to speed up Chrome releases and somehow we got jealous, so we decided to release a new official Plastic today!. So, a few days after 3.0 we're releasing 3.0.1.

Ok, the truth is that we do create weekly releases, but they normally don't go public, but there are a few things we wanted to make public asap (and of course we didn't have time to put them in 3.0...), so here we go...

Refactored items menu

The context menu on the items view was getting bigger and bigger and we almost didn't notice about it. But a few weeks ago we were doing usability testing with a small group of developers and we so it was simply enough. So we've decided to change a few things there. Please check here the changes. I know it's going to be a small pain for current users, but I can tell you in a few minutes you get used to the new smaller menu.

Reworked context menu for branches

The same as above holds true for branches... Again the menu was getting too big. So we made it smaller, regrouped some options differently and so on.

Multi-prefix support for the OnTime integration

It was requested several times by users, so we took some time during this sprint to implement it: now you're not restricted to "bugs" when linking branches to OnTime artifacts. You know, a small step for us but a big one for some of our users :-P

SSL support

An old friend that comes back. We reworked a little bit the support for SSL and now it's up and running again. We'll be posting an entry soon to explain how it exactly works and how to get it up and running. Now it is able to make the Plastic server listen in more than one port (ok, this was possible already) and one of them can be SSL.

SQL compact edition support

Yes, we're kind of addicts to implementing support for new database backends, so we just added SQL CE to the group. It is still a little bit obscure to configure (I mean, no doc, so if you want to use it send us an email) but part of the team is using it already down here for their replicated servers on the laptops (while the other part uses sqlite, including myself).

Merge tool re-styling

Probably the coolest change. It was "code-complete" for 3.0 but not yet fully tested, so we decided to wait a little bit more. But now is ready. What's new:

We've simplified the GUI, less buttons == easier to use.

We added a hint window so we try to explain a little bit how the 3-way merge works for newcomers. I'm fully aware hints are not as good as self explaining GUIs, but believe me 3-way merge is easier said than explained :O.

To solve manual conflicts selecting the default proposal Plastic does, you need now to click on "mark as resolved". Before just "passing through" got it solved, which was not clear. Of course by selecting or unselecting a contributor you set it as solved too. And now there's information on the top of the window explaining whether the conflict is solved or not.

Here's the screenshot for the new hint window:



And the new merge window:

Bug fixes

There are always bug fixes, of course! I'd suggest you to check the release notes online, but the most important one is an issue we had in 3.0 when uninstalling on 32 bit Windows machines. It's not a show-stopper but it complained about being unable to remove a 64bits key from the Windows registry. It is solved now. It was an issue with the installer, but a painful one if you're uninstalling 3.0... :(

Enjoy 3.0.1!!!

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.

Xmerge to merge refactored code

Monday, July 26, 2010 Pablo Santos merging 3 Comments

UPDATE 2015/08/25: Check the new updated content here.

It's been a funny week. We first announced 3.0, then announced Xdiff, later crunched Subversion and now we're finally explaining a little bit about what Xmerge is about.

Merging moved code

If you need to know what we're doing with diff and merge stuff, I'd strongly recommend you to read the post about Xdiff first. There's even a short screencast if you don't feel like reading :P.

Well, basically Xmerge applies the tech. we developed for Xdiff into the merge process. The scenario is simple:

• You've a file with some code.
• You go and move a method from the top to the bottom of the file.
• While you're doing this, on my own task branch, I go and change the method on its "original" location.
• Then we go and merge! Result? Nightmare unless you've Xmerge! :-P

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.

Agile Retrospectives: how to improve the meetings and the results

Saturday, July 24, 2010 Luix Agile , Scrum 4 Comments

I'll discuss in a couple of blogposts that I read recently in the book that I reference below, regarding how to improve the retrospective meetings.

What is a retrospective meeting?

In everyone's life, a retrospection is when someone stops and thinks about his/her life, evaluating good experiences, bad experiences and checking if he or she has learnt from those experiences in order to be a better person in society.

This, which most people do, in the agile methodologies of software development is called 'retrospective' and it is very useful in iterative development methods, to evaluate the progress made in every iteration. In this case we'll focus on SCRUM most of the time, but a retrospective can be applied to other Agile Methodologies.

Steps of a retrospective

A well-designed retrospective meeting should have the following steps:

1. Set the stage.
2. Gather data.
3. Generate insights.
4. Decide what to do.
5. Close the retrospective meeting.

These phases don't seem special or mystical things and lots of teams try to commit to them, more or less. So, the question is, why don't they get good results anyway? Well, maybe the problem is how and not what.

Who leads a retrospective

A retrospective meeting can be led by the manager or by any member of the team, or even this role can be assumed by a different person each time the meeting takes place. The person who leads the meeting mustn't participate in the discussions that will arise during the meeting, because his/her position biases the rest of the people's opinion.

In addition to this, it is very important to analize which parameters must be taken into account in a retrospective meeting. Some examples are:

• · Find ways to improve the practices.
• · Discover what we were doing well.
• · Understand reasons behind missed targets.
• · Find ways to improve our responsiveness to customers.
• · Rebuild damaged relationships.

To finish this section, let me mention two important statements that should be observed in every retrospective meeting.

1. Avoid blaming someone for an objective that wasn't achieved.
2. Try to make everyone participate in the meeting.

How long should it take

It depends.

It depends on the length of the iteration, on the complexity of the technology used in it, on the team's size, and the level of conflict that arise during the meeting. As a footprint: one week of iteration equals one hour of retrospective meeting. Anyway, there is no point in shortening or extending the meeting more than necessary.

On the other hand, the retrospective meeting must be prepared previously. The team must enter the meeting room with something prepared, at least some draft notes, and must be well informed about the issues to discuss.

How to prepare the retrospectives

The person responsible for the meeting must answer the following questions:

• · What is the goal?
• · Who will attend?
• · How long will it take?
• · Where will it take place?
• · How will the room be set up?

How to convince the people to prepare the meeting

The leader can send a short quiz by mail to every person that will assist to the retrospective meeting. Thus everyone will have to take a couple of minutes to think about the last iteration. After receiving everyone's answers, which will be kept anonymous, the results may be read aloud during the meeting, so that they may be interpreted as a summary of the team's insights.

What to do after the meeting

Try to make someone responsible for every action that has been decided during the meeting. Lots of retrospectives fail because, despite giving good insights and making good decisions, everything is missed because nobody takes care of those decisions. So, assign responsibilites and make commitments about those actions to be carried out.

And in the next article...

... I opportunely made a workaround to avoid explaining in detail the steps of a retrospective meeting. I wanted to set the ideas and give some advice. In the next article I'll explain each phase.

Furthermore, I'll explain a list of activities that can be done in a retrospective meeting to promote the participation of every member of the team. This is the first objective of a retrospective meeting and the most important one.

---

Bibliography:

Agile Retrospectives: making good teams great

Esther Derby & Diana Larsen

Version control scalability shoot-out!

Friday, July 23, 2010 Pablo Santos performance 18 Comments

Let's go straight to the point: we took 2 of the biggest mainstream version control systems and put them to work under really heavy load: 1 single server and 100 concurrent clients. And then we compared them with Plastic SCM 3.0.

Test environment

A mainstream QuadCore 64bits server with 4GB Ram. Nothing fancy at all, just what you can purchase with about $500.

100 desktop computers like the ones your team can use, all of them running Linux. They're quite heterogeneous: from single core 5 years old machines to newer 4 cores, from 1.5 Gb RAM to 4Gb.

Server and clients are connected by a simple 100Mbps network.

Sample repository

We tested with a variety of different repositories, from really small ones to larger ones.

The one I'm describing today is just a small one (and I can tell you results only get worse for the slow SCMs with more data...):

1376 files

66 folders

22,4 Mb when downloaded to a workspace

Test automation

In order to automate all the client machines we used PNUnit, you know, the extension we made to NUnit for "parallel" testing. Quite useful for load testing.

Test scenario 1 - working on trunk

A really simple scenario every developer is familiar with: just commit changes to the main branch.

Every client will do the following:

Modify 100 files

Checkin

Repeat 5 times.

Test scenario 1 - working on trunk - results

Ok, how our beautiful friends behave under really heavy load? Considering we tested with Subversion and Perforce, 2 of the most used version controls on the market, we expected high scalability... :)

We used SVN 1.5.7, Perforce 2009.2 64bits and Plastic SCM 3.0.

All results are using a Windows server and Linux clients, except for Subversion: we run the SVN server on Linux (dual boot server machine) because on Windows it couldn't handle more than 30 concurrent clients without consistently crashing (out of memory, 4Gb!!! and gone).

We run the same test described above with 1 client, 10, 20, 50 and 100. Check the results here:



Surprised????

The two old irons doesn't scale that well at all, uh? ;-)

Plastic is using a SQL Server backend and it seems it can handle the load much better than the others, even doing trunk development.

Test scenario 2 - working on branches

The second scenario tries to reproduce a "branch per task" pattern, something we strongly recommend with Plastic.

The scenario is as follows:

Update to trunk

Create a branch from trunk

Switch to it

Perform changes on the branch (about 50 modified files)

Checkin changes

Go to step number 2 (5 times)

Test scenario 2 - working on branches - results

We always say most of the version control systems out there are not ready to handle branching, and we always hear people asking why.

Ok, a picture is worth a thousand words.



If you miss some data point in one of the version control systems compared is not because of a mistake, the reason is that the server simply starts locking too much, rejecting clients and making the test fail (even considering that the test is able to handle retries if it gets rejection errors).

More data

I'll be sharing the data regarding the Plastic server running on Linux in the coming weeks. We used MySQL on Linux and while it is slightly slower, it still consistently beats all competitors.

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.

"Move" support in xdiff

Thursday, July 22, 2010 Pablo Santos merging , news 7 Comments

One of the big things we just released in 3.0 is the new Xdiff. We call it "cross diff" because it can locate code that has been moved, and we used to draw it on paper with "crossing lines".

Ok, what is all of this about and why is it so good? Let's go.

Let's start with a piece of code like the following:



Then we move a piece of code a little bit down:



And we slightly modify the moved code as you can see here:



Let's see what Plastic Xdiff can do:



It is able to identify the code as "moved" even when it has been modified. And you can click on the "subdiff" to actually run an independent diff on the moved fragment as you can see below.



Cool, isn't it?

We can do this with any programming language since the algorithm is not based on parsing but in plain text move detection.

Check the following screencast to see it in action.




Don't forget to check the next step too: Xmerge!

Enjoy!

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.

Plastic 3.0 is out!

Friday, July 16, 2010 Pablo Santos news 2 Comments

Hello PlastiKers of the world!

We’ve great news: Plastic SCM 3.0 is out!

3.0 is, of course, our greatest release so far, close to 400k LOC, and it comes fully packed with new exciting features, usability improvements and performance tweaks.

If you’re already using Plastic you’ll find many of the things you ever asked for are included here (we do listen to our users and react fast, as you all know) plus a full pack of new stuff (some of it never seen before in the SCM arena).

If you never used Plastic so far I strongly recommend you to take a look into 3.0. You’re probably using SVN, Git, Clearcase or Mercurial (if you’re using something as arcane as CVS or SourceSafe… simply drop it now! :-P ), which are much better known than Plastic but are several step behind us: look at our GUI, look at our branching model, look at our storage possibilities, look our new Xmerge or the new distributed code review system.

Ok, let’s see what’s new:

Built-in distributed code review: built-in code review system that tightly integrates with branches, changesets and labels. A review can easily be created from these three elements and then replicated, enabling a distributed review process.

Shell extension: Windows Explorer integration that allows developers to perform all the version control operations within Explorer. All the GUI views are accessible from the shell extension too.

New Subversion and Perforce importers: improved Subversion importer (both performance and usability) and a totally new Perforce importer.

New "pending changes view" on the GUI: now checkouts (checked for edit from the GUI, command line or the plugins), changed (modified outside Plastic control) and privates (potentially new files) can be checked in together from a single view.

Xmerge / Xdiff 2.0: the merge and diff tools get updated with "cross merging" technology capable of detecting moved (and modified) code within the same file. Xdiff can find code that you have moved between two revisions, even if it has been moved and then modified, and render it correctly so you can see it's been moved. Xmerge will help you merging together code that has been moved on one revision (and potentially modified) and also modified on a second revision. This is the first merge/diff tool supporting this feature on the market, so it's really worth taking a look into it! :-)

External data storage: it is possible to "extract" data from file revisions in a repository so they don't consume main database storage and save them on secondary devices (like DVDs, hard drives and so on). It is possible to plug the media to the server for transparent acccess or to access the "extracted" data directly from the client machine (Plastic will prompt to introduce the right media when accessing a "extracted" revision). It is useful for projects using really big files.

Annotate support on GUI: now annotate (cm annotate or cm blame) is also supported from the GUI on a graphical way.

SQLite backend support: Plastic servers can now use SQLite as backend. SQLite adds a new backend to the existing set of supported databases: Oracle, MySQL, SQL Server and Firebird. SQLite is very fast on Windows, Linux and Mac OS X environments, but it is better suited for distributed development (a developer running a small footprint server on his laptop or workstation). SQLite is the default on Linux and Mac OS X evaluations.

Selector explorer: it is possible to explore branches, labels and changesets without having to download them to a workspace. Advanced users can edit the selector to try more complex configurations.

Performance improvements: as usual every new Plastic release is faster than the previous one. We thoroughly tested Plastic with big workspaces (>250k files and 40k directories) and big repositories in several scenarios: from heavy load (hundreds of concurrent users (computer simulated) against a a single server) to single user operations (quickly adding a big workspace into a repository) where we can consistently beat all our major competitors.

I'll be talking in more detail about all the new features in the coming days. Stay tuned!

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.