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.

Continuous integration future?

Friday, March 28, 2008 Pablo Santos 30 Comments

A few days ago I was re-reading the book "Continuous integration" by Paul Duvall. I find it a really interesting reading, especially when you use agile practices.

The book dates from mid 2007, so is quite new, and there's a chapter at the end of it which really surprised me. It is titled "the future of continuous integration", and it focuses on two interesting questions:

  • How can broken builds be prevented?
  • How can builds get faster?

The first question is not a concern for us internally, but the second one is probably one of the toughest problems we've reached here at Codice. Can they be solved with version control?

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.

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

Branch explorer tour

Tuesday, March 25, 2008 Pablo Santos 2 Comments

It's very likely you've drawn a diagram like this one at least once... (and I'll bet probably you do it very often).



It is just a tipycal branch diagram, showing the relationships between branches, merges and labels (changesets are not normally displayed when you draw the diagram manually :-P). It clearly shows when a merge happened (from a project point of view) or when a label (and hence a baseline) was applied.

The folks at Microsoft's Team System group are dreaming about releasing something similar in the future.


The good news is that Plastic already have it! :-)

The branch explorer released with Plastic 2.0 is all about representing branch evolution... the kind of stuff you'd usually draw on paper... but now rendered at your screen.



So, what I'll be showing is a quick tour through the branch explorer, and how an entire branching and merging cycle can run from it.

Watch the entire tour 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.

Custom file types

Monday, March 24, 2008 Daniel Peñalba 3 Comments

Plastic SCM handles two different file types: binaries and text files. By default, Plastic tries to identify a newly added file by using an internal algorithm and a built-in list of known extensions. But sometimes a file that should be binary is identified as text or viceversa.

When a file type is interpreted by Plastic SCM as binary, it is not possible to show the differences in text mode. This is not a problem because it is possible to change the type of a revision. When you change the type of a revision, future revisions of the item will be of the same type.

But now, with Plastic SCM 2.0, users can associate file extensions to file types.

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.

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

How to configure MySQL backend in Plastic SCM 2.0

Monday, March 24, 2008 Ruben 7 Comments


It's very simple to set up, you only need to create (or edit) a file named 'db.conf' at the server installation directory.

Its content must be like the following:
Note: The line <ConnectionString>....</ConnectionString> must be on one complete line, it has been splitted here for the sake of clarity.


<DbConfig>

<ProviderName>mysql</ProviderName>

<ConnectionString>
Server=_SERVER_;User ID=_USER_;Password=_PASSWORD_;Database={0};Pooling=true
</ConnectionString>

<DatabasePath></DatabasePath>

</DbConfig>

replacing the parameters _SERVER_, _USER_ and _PASSWORD_ with the appropiate ones according to the server configuration that you want to use. Thus, a valid 'db.conf' file in our development environment would be:


<DbConfig>

<ProviderName>mysql</ProviderName>

<ConnectionString>
Server=venus;User ID=myuser;Password=mypwd;Database={0};Pooling=true
</ConnectionString>

<DatabasePath></DatabasePath>

</DbConfig>

Finally, we must set the mysql configuration parameter max_allowed_packet to support up to 10MB. If you require more information about how configure this parameter, you can take a look at this article.


Updated articles are maintained in the knowledge base of Codice Software at: http://www.plasticscm.com/infocenter/technical-articles.aspx

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

Logging to the Event Log

Monday, March 24, 2008 Pablo Santos 0 Comments

By default Plastic server logs both activity and errors to a file (loader.log.txt) located at the server's installation directory.

Since Plastic uses log4net as logging mechanism, it is very flexible to customize logging messages and output.

The following script shows how to configure the log (editing loader.log.conf at server's directory) to output errors to the Windows Event Log.

<log4net>

<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%message%newline" />
</layout>
</appender>

<appender name="FileAppender" type="log4net.Appender.FileAppender">
<file value="loader.log.txt" />
<appendToFile value="true" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%message%newline" />
</layout>
</appender>

<appender name="EventLogAppender" type="log4net.Appender.EventLogAppender" >
<threshold value="ERROR" />
<applicationName value="Plastic Server" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%message%newline" />
</layout>
</appender>


<logger name="UpdatePerf">
<level value="INFO" />
</logger>

<logger name="Transaction">
<level value="INFO" />
</logger>

<logger name="Operations">
<level value="INFO" />
</logger>

<root>
<level value="ERROR" />
<appender-ref ref="FileAppender" />
<appender-ref ref="EventLogAppender" />
</root>


</log4net>


The sample also shows how to configure Plastic logging to work with selected sources. In this case we're selecting all the transaction, performance and operations sources.

We normally use the following conversionpattern to define appenders:

%date %thread %property{UserID} %property{TransactionID}
%property{ClientMachine} %-5level %logger -
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 2.0 on Mac

Thursday, March 13, 2008 thewhiteline 0 Comments

The introduction of Plastic 2.0 saw the inclusion of MySQL as the server back-end to store the repository. Not only does this open up a number of excellent possibilities and improvements for Plastic, but also makes the Mac OS X server functional. Plastic 2.0 is still in development but stable enough that following a few simple steps, we can get the client and server operational on the Mac.

Let's start by downloading all the components we'll need.

Begin by downloading the Plastic 2.0 Binary file archive from Codice Labs and extract the zip file. I chose to put it into my user directory as ~/Plastic

Next we'll need to grab Mono 1.2.6_6 from the Mono Project. After downloading, run the installer package.

Finally, we need a MySQL server. The quickest to get going is MAMP 1.7.1. Install this into Applications.

Now it's time to do some configuration of the Plastic server. Launch the MAMP application. This will fire up the MySQL server and keep it running as long as MAMP is running . By default it uses port 8889.  In the directory ~/Plastic/server edit the file db.conf to be:

<DbConfig>
    <ProviderName>mysql</ProviderName>
    <ConnectionString>
         Server=localhost;Port=8889;User ID=root;Password=root;
         Database={0};Pooling=true
     </ConnectionString>
    <DatabasePath></DatabasePath>
</DbConfig>

The line starting Server= contains the MySQL server's network address and account details. I've used the defaults for MAMP. To configure the Plastic server, launch Terminal and issue the commands:

$ cd ~/Plastic/server
$ mono clconfigureserver.exe 

Follow the on screen prompts. I entered 1 for English language, then 1 for NameWorkingMode and left the default port at 8084.

Now start Plastic server with:

$ mono plasticd.exe --console

The resulting output should be:

Creating ServerSink
Plastic SCM daemon up. 2.0.85.0

From a second terminal we now setup the client. Start by configuring the client with:

$ mono clconfigureclient.exe

Again following the prompts, I used 1 for English, 1 for NameWorkingMode and localhost for the server address with port 8084.

Finally, check that the connection is working with:

$ mono cm.exe lregrep

The output should be:

 default 1 default localhost:8084

You now have a working Plastic repository and command line client.

To start the GUI use:

$ mono plastic.exe

Make a workspace and off you go.

0 comentarios: