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.

Smashing the bug for fun and profit

Wednesday, May 30, 2007 Pablo Santos 0 Comments

Yes, the title is not very original, but I always wanted to write something similar since I first read this article long, long ago.

Well, so far you've watched Plastic 3D version tree displaying huge trees, running on Linux, controlled by a gamepad but... have you ever seen it wii-moted?

Watch the following video and enjoy!

P.S: Wait till the end to see the smashed bug! ;-)

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.

Fear of merging

Tuesday, May 29, 2007 Pablo Santos 2 Comments

Yes, at the end it is all about merging ;-)

Well, now I have the opportunity to talk with people all around the globe who start using Plastic SCM for their development, and from time to time (more often than not) I find developers who are totally scared about branching.

Did I say branching? Ok, as Linus mentioned the problem is not branching but... yes, merging!

-Are you crazy? If both of us start making changes on separate branches we will end up in big trouble? How is Plastic going to reconcile changes together? Does Plastic understand the code?

-Well, no, it doesn't -I say- but there are algorithms to merge block of lines together: if you change one block and I change other block, they will be merged, no problem, if we both change the same line... Plastic will ask you which one is the right one...

-Uhm... I still remember my old days with CVS when I took several hours to put changes together and...

-Gotcha!

Yes, the good old CVS merging problems... once you suffer it you won't ever forget... or at least it seems. Well, and if you replace CVS by SourceSafe you get the same story... (I won't talk about any other system, although I could put more names... :-P)

Well, then I show them how Plastic manages the merge process, how merge tracking works, how they can be sure they can repeat merges without any problem, how refactoring is also supported, and they their faces change... hey, but then I can do this and that and.... Yes, you can. There was only one reason you were not doing parallel development before... your tool couldn't afford it! (which reminds me: there is only one reason you would by CAR X: you can buy CAR Z :-P)

Watch the following screen-cast and see a simple example merging a WinForms window being modified by two developers at the same time (one puts a button, the other one puts a menu).



And if you prefer full-screen mode you better click here.
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.

2 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.

Linus Torvalds on GIT and SCM

Sunday, May 20, 2007 Pablo Santos , , 68 Comments

I just finished watching the speech Linus Torvalds gave some days ago at Google, basically talking about GIT and Source Control Management.

He has really strong opinions but I think the video is really worth watching.

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.

68 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.

New query system

Friday, May 18, 2007 Dave 1 Comments

While part of the team was spreading the Plastic word in Oxford, Rubén has been working hard to complete the new query system and we are already using it internally. I started looking at it today, and found it to be very powerful! Just some samples:

Query for all markers on the current workspace:



C:\vb3>cm find marker

354 17/05/2007 10:51:35 excel dave
1665 18/05/2007 16:02:08 excel2 dave


All items on a given baseline (signaled with a marker):


C:\vb3>cm find revision where marker = 'excel' --format={item}

c:\vb3
c:\vb3\forest
c:\vb3\forest\TreeManifest.doc
...


Revisions changed from changeset 10 on branch /main/clio:


C:\vb3>cm find "revision where changeset > 10 and branch = 'br:/main/clio' "

1586 17/05/2007 10:58:52 dir 11 dave c:\vb3#br:/main/clio#3
1597 17/05/2007 10:58:52 dir 11 dave c:\vb3\forest#br:/main/clio#0
...


Items changed between changeset 10 and 13, display changeset and item name


C:\vb3>cm find revision where changeset between 10 and 13 --format="{changeset} {item}"

10 c:\vb3
10 c:\vb3\forest.removed.0.removed.0
12 c:\vb3\forest.removed.0\ForestWhitepaperES.doc
...


Items changed from baseline 'excel2' to 'excel3' (baselines signaled here as markers):


C:\vb3>cm find revision where marker = 'excel3' and not marker = 'excel2' --format={item}

c:\vb3\WindowsApplication1\Form1.cs
c:\vb3\WindowsApplication1\Form1.resx
...


Will keep you updated!

1 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.

SCM meeting at Oxford, UK

Friday, May 18, 2007 Pablo Santos , 0 Comments

We've been at Oxford, UK, at the 3rd Conference and Exhibition of the British Computer Society Configuration Management Specialist Group (BCS CMSG). During the past two days (15th and 16th May 2007) we have been presenting Plastic SCM at our booth at Oxford.

We made a demo showing Plastic SCM performing a full development cycle, including branching and merging patterns.
On Wednesday we gave a speech about freeride software development. If you are interested you can find the slides here.
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.

Plastic SCM GUI testing

Thursday, May 10, 2007 Pablo Santos , 0 Comments

Last week I wrote about the three basic layers of testing we run here at Codice to check Plastic SCM functionality release after release.
Each weekly release (or almost weekly depending on the specific workload) passes through long hours of automated GUI testing. As I mentioned we are currently using AutomatedQA TestComplete which is a pretty good tool specially considering the price/quality relationship.
We also run the GUI tests each time a task is finished (and its associated branch is closed), so at the end much testing hours are run.
The following screencast is just a short fragment of a test run, and shows the Plastic GUI under heavy user testing.

Nowadays several tools are available to run those kind of tests on Windows based systems, but there is a huge lack of tools for the Linux world. The good thing with TestComplete is that it is good enough (and getting better release after release, indeed our team is busy today migrating to the last 5 release, and it seems distributed testing runs better now).
The one I know for the Linux world is: http://www.redstonesoftware.com/technology/userPerspective.html, but I never had the chance to try it.
There are other options like http://www.redhat.com/magazine/020jun06/features/dogtail, http://www.eclipse.org/tptp/test/documents/userguides/Intro-Auto-GUI.html or http://www.instantiations.com/index.html.

Happy testing!
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.

CMMi Level 2!

Monday, May 07, 2007 Pablo Santos , 9 Comments

Last March 15th we achieved CMMi Level 2, and SEI has just officially published the results today.
Codice Software becomes the first Spanish SME being awarded with CMMi. But our case has an special interest because we are agile practitioners, we are using SCRUM for almost two years already, and many claim CMMi and SCRUM to be incompatible.
SCRUM focuses on delivering software fast, on code instead documents, and on short release cycles, features which have become a part of our internal working methods since the beginning. CMMi asks for more strict processes, but at the end the key point is doing what you are suppposed to be doing according to your own definitions. Congratulations to the whole team!
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.

9 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.

Command line Plastic Testing...

Sunday, May 06, 2007 Pablo Santos , 2 Comments

I already wrote about the way we are doing testing at DDJ months ago, when I first introduced PNUnit (Parallel NUnit).
We are currently using 3 layers of tests to check Plastic SCM:


* The first one is conventional unit testing using NUnit. Here we check the basics: database storage, merging, basic security, selector resolution and so on.
* The second one is PNUnit testing, and I will be talking about this one today, so let's go to the last one.
* The third one is GUI testing: we are using AutomatedQA's TestComplete to create and run graphical tests, with very good results. We use TestComplete to check all the functionalities that the GUI tool provides and we repeate the tests under different configurations: W2K, XP, W2003 and using different database backends. We also try different authentication setups: active directory, LDAP (running on a Solaris SPARC server) or just local user names. The good thing about TestComplete is that you can also create "concurrent" tests: you launch a client in one box, another client in another box and a server on a third one and you can sinchronize them to perform combined actions. The weak point here is that TestComplete doesn't run on Linux...
Another key part in our testing environment is VMWare (www.vmware.com): to try different setups (except performance tests) we use virtual machines. This way is easy to start testing at a certain known configuration, release after release.
We run NUnit, PNUnit and a reduced set of the GUI tests each time we finish a certain task. If they all pass, the task is marked as finished.
Once a week we create a new internal release, and then the same tests are run again, but now also trying different OS combinations, as I mentioned before.
There is a forth testing layer that we use to make stress testing: we use an external 50 Xeon Cluster (we rent it by hours) to put Plastic under heavy load simulated situations: with 50 CPUs you can really launch lots of clients against a single server... So this is a good benchmark for our system.
Ok, but, what did we go for PNUnit in the first place? What is it exactly?
Most of the time counting on a unit test framework like NUnit is enough, but what if you want to do the following:
- Start a server
- Launch a client and perform several commands: adding a couple of files, check them in and recover its contents to verify they are correctly stored. With Plastic you would time something like:

$ cm add file00.c file01.c
$ cm ci file00.c file01.c
$ cm getfile file00.c#br:/main#LAST -file=filetocheck
$ cm getfile file01.c#br:/main#LAST -file=filetocheck2

And then will check filetocheck and filetocheck2.
Ok, you could do the following with simple NUnit: you could start the server core using the code, and also a client, and perform the commands. But most likely instead of really "typing the commands" you would be using the internal APIs, which is good, but not exactly the same. And even more, what if now I want to start the server on one machine and the client in another one?
Ok, you could just create some sort of shell script and try to automate the process but:
* It won't be (most likely) portable between Windows and Linux
* You won't have all the NUnit commodities (like asserts, tests results and so on)
* What about sinchronization? You need to wait for the server to be correctly started before launching the client, otherwise the test will fail...
And these were basically the reasons why we decided to implement PNUnit at the end of 2005, to create the core of our internal testing system.
PNunit is some sort of NUnit wrapper, and provides:
* A way to start tests remotely on different machines (provided they are running the PNUnit "agent")
* A way to gather test results from the multiple testing machines
* Synchronization facilities (a barrier mechanism) so that you can easily sinchronize different tests
* A method to configure "test cases" based on XML.
The last point is very important because this way you can create many different test configurations based on the same code. Let's go back to the simple example adding just two files. It could be named AddTest. Imagine we have a test that justs launches the Plastic Server, named ServerTest. Both tests are implemented on the assembly cmtest.dll, and specifying the right configuration file we can create different test combinations, running the same code on the same machine (for instance as smoke tests for developers) or on different ones (checking real network operations).

Inside the TestConf block there is a param named Machine which specifies where the test has to be run. So configuring different scenarios is really, really simple.

Well, but how does the real "test code" really looks like? We have built some utility code to wrap our testing code, so that when we write a new test we don't have to care about barriers and so on (although it has to be done to create special scenarios from time to time). The test launching code looks like:



public static void RunTest(string methodTestName, ExecuteTestDelegate test)
{
string testName = PNUnitServices.Get().GetTestName();
try
{
string[] testParams = PNUnitServices.Get().GetTestParams();
string wkbasepath = testParams[0];
string servername = testParams[1];

PNUnitServices.Get().WriteLine("The client should wait until the server starts");
PNUnitServices.Get().InitBarrier(Names.ServerBarrier);
PNUnitServices.Get().InitBarrier(Names.EndBarrier);

// would wait for the server to start
PNUnitServices.Get().EnterBarrier(Names.ServerBarrier);

// execute the test
test(testName, servername, wkbasepath);

// notify the end
PNUnitServices.Get().EnterBarrier(Names.EndBarrier);
CmdRunner.TerminateShell();

}
catch( Exception e )
{
PNUnitServices.Get().WriteLine(
string.Format("{0} {1} FAILED, exception {2}", methodTestName, testName, e.Message));
throw;
}

}

As you can see we initialize a couple of barriers: this means telling to the "test coordinator" (the "launcher") that it will have to handle two different barriers, and then we enter the ServerBarrier: until the server doesn't reach this point, the client won't be able to proceed... So we ensure everything is ok when the client starts running. Then we execute the test, and at the end we pass through the EndBarrier notifying the end of the scenario.

And how does "real tests code" looks like?


private void DoAddCheckInCheckOut(
string testName,
string servername,
string wkbasepath)
{
string wkpath = null;
try
{
string repname = "mainrep-" + testName + "-DoAddCheckInCheckOut";
wkpath = TestHelper.CreateRepAndWorkspaceWithSelector(
testName, servername, wkbasepath,
repname,
new SelectorTest (SelectorTypes.SELECTOR, new string[] {repname}));

// check out parent directory
CmdRunner.ExecuteCommand(
string.Format("cm co . -wks={0}", servername), wkpath);

// add a file
string filepath = Path.Combine(wkpath, FILE_NAME);
FSHelper.WriteFile(filepath, FILE_CONTENT);
CmdRunner.ExecuteCommand(
string.Format("cm add {0} -wks={1}", filepath, servername), wkpath);

// check in
CmdRunner.ExecuteCommand(
string.Format("cm ci {0} -wks={1}", filepath, servername), wkpath);

// check out
CmdRunner.ExecuteCommand(
string.Format("cm co {0} -wks={1}", filepath, servername), wkpath);

// check the file content
Assert.IsTrue(FSHelper.ReadFile(filepath) == FILE_CONTENT,
"The file {0} doesn't have the expected content", filepath);

// check in parent dir
CmdRunner.ExecuteCommand(string.Format("cm ci . -wks={0}", servername), wkpath);
}
finally
{
// clean up the workspace

if( wkpath != null )
FSHelper.DeleteDirectory(wkpath);
}
}

So using specific testing classes (like CmdRunner) we end up "typing commands" at code, and easily being able to add new test cases to check Plastic's functionalities.

The good thing is that adding a new test case is so simple that before fixing a bug we always create a PNUnit test, so we somehow follow "test driven development" not only when adding new code but also during fixing...
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.

2 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.

New PlasticSCM-Linux installation features

Thursday, May 03, 2007 Daniel Peñalba 1 Comments

We have been working on the installers for the platforms supported. We tried to make installation even easier!

As a result, the main innovation is the installation upgrades which we are releasing soon. These will easily update one version to a newer one. This new feature will be included on PlasticSCM next release and we will keep you informed through this blog.

Meanwhile, now you can start using Linux installers. They can be downloaded from here.

They have been successfully tested on the following Linux versions:
  • RedHat
  • Suse
  • Fedora
  • Debian
  • Ubuntu

Here you can find a brief installation guide, to help you on installation process:

Client pre-install Requirements

Server pre-install Requirements

Eclipse pluing pre-install Requirements

  • Eclipse 3.1 or later.

Installation Steps

  • Set execution permissions to the installer and run it.
  • Select the installation language
  • Accept license agreement.
  • Select the installation directory. You must enter a writable path. If directory doesn’t exist, installer will create it.
  • Select installation components.
  • If the Server component has been selected then the Firebird server must be restarted, and you will need to introduce a valid username and password for the Firebird server.
  • If Eclipse plugin component has been selected, installer will need where is located Eclipse base directory.
  • Required files will be copied in the hard drive.
  • Configure installed components. If the server component has been selected, installer allows specifying whether to start it at system boot or not.

Configuration parameters

Server configuration parameters

  • Select Server installation language.
  • Select users/security authentication mode
  • If LDAP authentication mode was selected you must enter the following parameters
  1. Server: IP or machine name of LDAP server
  2. Port: Default is 389
  3. Domain: Domain of LDAP configuration (i.e. factoryname.com)
  4. Username: LDAP valid user name
  5. Password: Password of previous username account
  6. Type of LDAP server: Active Directory if LDAP server is a Windows based LDAP server, or LDAP otherwise.
  • Server port: Default is 8084

Client configuration parameters

  • Select Client installation language.
  • Select users/security authentication mode. Normally, this configuration should be the same as the server’s. If you don’t know this configuration, ask your administrator.
  • Workspace server: Name or IP of the machine where PlasticSCM Server is installed.
  • Port: Default is 8084

Post-installation Steps

If you chose to skip component setup during the installation, you can configure later both client and server through the ‘configureclient’ and ‘configureserver’ binaries, available under the installation directory.
The server can be managed with the script ‘plasticd’ (copied by the installer in /etc/init.d, and also in the install directory) supplying any of these arguments:

  • Start
  • Stop
  • Restart
  • Status

Usual Problems

If any problem should arise after the install, consider the following items:
The user who does the installation or anyone who wants to use Plastic SCM must have the following environment variables:

  • LD_LIBRARY_PATH pointing to the folder ‘lib’ on the mono directory installation
  • PATH pointing to the folder ‘bin’ on the mono directory installation
  • Wrong Firebird username/password
Dani Peñalba
Yes! I was the first employee to join Codice!
I own the record in number of check-ins to the Plastic repository. And you can find me working on every single area of Plastic.
I'm also a professional guitar player and I like scuba diving, too. You can reach me at @danipen00.

1 comentarios: