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 Remote Access

Saturday, January 27, 2007 thewhiteline 0 Comments

For those of us who have worked on large scale software development across multiple sites and/or countries, you've probably come across ClearCase and ClearCase MultiSite. ClearCase MultiSite replicates a ClearCase VOB (repository) between installations. It makes clever use of e-mail to send differences between ClearCase servers. Engineers then simply access the replicated VOB as if it were held locally, in fact it is. All good stuff, but requires quite a bit of administration.

Plastic on the other hand doesn't support repository replication and doesn't need to. Simply access the repository from the remote client over TCP/IP. To do this we need to switch the Plastic server to use IP addresses for it's server name. Edit server.conf and add an entry <ServerName> IP addr </ServerName>. Then restart the Plastic service. Open port 8084 on your firewall(s). Ensure that the IP address you entered is an externally accessible address and not a LAN address. Then setup your router to forward port 8084 to the server.

On your clients re-run the client configuration tool and enter the server IP address. Of course, the client will have to open port 8084 on their network as well.

If the server is using Local Users authentication the user account names must match on the client and server. More extensive name serving can be performed with LDAP or Active Directory offering additional security.

I think you'll agree that Plastic is simple to setup for external access offering the benefits of low administration, centralized storage and remote client access over the Internet.

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 on SLED

Wednesday, January 17, 2007 Pablo Santos 0 Comments

As you can see from the last post, we are about to release Plastic SCM on Linux. Server has already been working for months, and the same can be said for the command line client, but we had some issues with the GUI tool due to small problems on the Windows Forms implementation on Mono/Linux.

So during the next weeks we will continue testing it before making an official release. I'm really glad about how it looks like now on the SLED environment.
Our intention is also making a VMWare SLED image available so that users can easily download it and start working...
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.

We are about to release on Linux

Wednesday, January 17, 2007 Daniel Peñalba 0 Comments

We have been working to release a linux PlasticSCM version. Thanks to our collegues of Mono and Bitrock, this target is quite close.

An easy-installation of the product is one of our possitive points, and we want to keep it for the linux world. In non windows operating systems, we can perform graphical or text installations. You can see some snapshots of PlasticSCM linux installation below.

This is the graphical installation mode:

This is the text mode installation:

And there is the text configuration tool:

The installer also has an unatteded mode. With this feature, you can perform massive unatended installations and configurations of PlasticSCM. You will be able to install PlasticSCM in a lot of machines, only with a simple two-lines script!!

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.

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.

Diff debugging revamped

Monday, January 01, 2007 Pablo Santos 1 Comments

The first version control system I ever used was Source Safe. The few things I remember about my Source Safe experience are:
- Hey, this is better than zipping code back and forth.
- Somebody has my file locked... I can't continue working.
- Check in everything when you're done.
No, at that time I was not really getting the most ouf of the version control system but now I understand old good Source Safe was not the way to go.
Most of the developers out there think about the underlying version control system (when they have one) just as a way to actually release their changes. That's it. And it is often something painful to use. Programmers don't usually enjoy using the SCM but exactly the opposite.
The thing I like the best about Plastic is that it is not a tool designed to help managers control people, but to help programmers to be more productive. Ok, you can find features to help project management, and even project control, but they are derived from programmer's productivity facilities. This is an important point to remember.
Ok, why I say that? Let me introduce the topic I'll be writing about today. I was thinking on posting about the way I use Plastic to find bugs in the code. Then I found Martin's Fowler post on DiffDebugging. Yes, whatever you think about there is always someone else who thought about it before. Ok, let's go.
Most of the people I find using SCM systems use one of the two following patterns:
- Use the SCM just to check out and check in code.
- Use a continuous integration approach.
Of course there is a huge benefit on the second approach compared to the first, because it requires a well stablished build mechanism to be present.
But both of them fail on really "helping" the programmer in his daily work. Fowler's post introduces the issue of "debugging" using diff tools. What does it mean?. Ok, as programmers we are all used to the following situation:
Hey, this was working only half an hour ago, what happened? (you can replace "half an hour" by "half a day", "week" or whatever your prefered time unit is). So if you're using a version control system you can check your file's revision history, and go back "diffing" between previous versions. It is a very handy tool to find and fix problems. With Plastic we have introduced not only a "log" or revision history, but a 3D version tree which can show both history and revision's relationships in a very handy way.
Well, it is clear that version control can even help during debugging sessions but, if you are using Source Safe, CVS or Subversion your team is probably using just one development branch: so people (as it happened on my first source control experience) just check in code when they're done. Then "DiffDebugging" is not as useful as it should be. Let me explain: using the mentioned model you just check in when everything is done, so you won't prevent the following scenario: you're working on something (still intermediate) and you have to make some major change. The usual way to prevent the it was working but now it doesn't situation is saving your code with a different name before making changes (foo.c.old, foo.c.back, foo.c.back-the-good, sounds familiar?), or even better (I wanted to say worse), commenting code in and out. This can end up with:
a) Commented code kept into the mainline for what if I need it later cases. (You won't never need it later, granted!,but the ugly commented pieces will remain there forever)
b) Programmers not getting the benefits of "DiffDebugging": problems not only arise between good revisions but also between intermediate ones, the ones the programmers are working on and will never be commited to the source code control system because they are not yet finished.
Is there a solution? Yes, there is one: branching patterns. Plastic SCM handles branching with enough agility to allow developers create as many as they want: this way they can use branch per developer or even branch per task approaches. In any of them they can check in as many times as they feel they need to (once they are used to... quite often), so DiffDebugging enters the scene again, allowing them to search for mistakes in their own ongoing work.
With extensive branching usage developers gain a big undo button allowing them to exactly check everything being modified.

Fowler states most of the time I see diff debugging is during an programming session when you have local version control. Here local version control is an added service of the regular version control system.
In fact every new age version control system will talk about private branches or sandboxes or whatever that will provide developers isolation and full advantage of DiffDebugging at the same time.
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: