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.

Second day at the GNOME & Mono Festival of Love 2012

Thursday, June 28, 2012 Amalia , 0 Comments


Hi from Boston!!

Today we started to build MonoDevelop plugin. We were working on it with Alan McGovern. He is contributor at MonoTorrent.We have only a light structure (first steps), but it works in MonoDevelop.

NERD building is the our headquarters. We are in the Microsoft floor and let me tell you, the offices are fantastic with a lot of amenities that make your work a pleasure. If you watch through the window you can see the Charles river and the rooms are huge like everything here!

arevalo's team in NERD building (Boston)


We were very lucky because we were able to watch the Portugal-Spain match (Euro2012) during lunch. We were in an Irish pub (close to the MIT museum) surrounded by Portuguese fans. It doesn't matter. We won. Vamos España!!

In the afternoon we continued implementing the Plastic SCM extension for Mono Develop
At the end of the day we toured in other part of Boston: the Town Hall, AppStore and the Top of the Hub a restaurant and lounge on the 52nd floor of the Prudential Tower. It has the most amazing views of the city you could ever image.  


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.

Our first day at the GNOME & Mono Festival of Love 2012

Wednesday, June 27, 2012 Amalia , 0 Comments




Hey guys, we are in Boston at the GNOME & Mono Festival of Love 2012. During the next 7 days, Boston will be the world's capital for Mono developers.

Our first day here has been great. We have been touring all kinds of important places around the conference. The MIT building is fantastic. It has an incredible museum with a lot of cool machines, also known as kinetic sculptures, built by Arthur Ganson. You can see machines dating back to the beginning of the 20th century all the way up to the latest robots created by and for the MIT crowd. We were also lucky enough to have seen a Lisp machine one of only 7,000 first-run personal workstations ever created. Incredible. 

One other important building in this event is NERD, or the Microsoft New England Research and Development Center. Its the venue of the conference. It’s a really nice place.

At night, we enjoyed hanging out with other attendees at the festival, making some new friends, and getting settled in. And that’s it for the first day!

See you tomorrow!
Ruben & Jesus (Plastic SCM) at MIT
Ruben & Jesus at MIT

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.

Simulating dynamic inheritance in Plastic SCM 4 (or almost so)

Tuesday, June 26, 2012 Ma Nu 1 Comments

As you know, the old dynamic inheritance is not available in Plastic SCM 4. It was a Plastic SCM 3 feature that was cool, but hard to understand, so it was overlooked by a large number of development teams.

How it worked

The child branches created with dynamic inheritance didn't have a static branch base; the base was always changing as soon as its parent branch was.

Plastic SCM 3 dynamic inheritance
This was very useful when, for example, the core system code was modified in the main branch. Then all the child branches had the change introduced automatically with only performing an update operation.

Inside Plastic SCM 4, the same behavior can be easily achieved by merging the last main changeset into the task branches, but we have to admit that this is a manual operation and in a huge environment with a lot of developers the periodical merge operation can be easily forgotten.

That being said, it seems that the dynamic inheritance was a really powerful feature. Indeed it was, but let's see the not-so-pretty side too.

Dynamic inheritance weak points

It was slow. The workspace resolution was an expensive operation.
Very complicated to use and understand for a regular user.
It was really easy to end up with completely wrong or broken code.
You were never able to be 100% sure of a changeset configuration. It was "selector-depending".
The distributed scenarios were complete madness.

Simulating the strongest part

Having the "core" code changes automatically applied in the working branch was great, now using the new "merge-to" feature we can get it back.

The "merge-to" feature is able to perform merge operation on the fly, without having to change the current working branch and merge it manually. We are able to use the Branch Explorer and say, "Merge this branch with this other branch," and the merge is done in the server. Obviously the merge operation must be automatic, both contributors merges are not allowed. This restriction was also present in the Plastic SCM 3 dynamic inheritance system.

After check-in trigger

I'm going to simulate the dynamic inheritance system using a c# trigger. This trigger will be monitoring the check-in operations affecting our desired branch -- in this case the /main branch. Every time we have a new changeset in the /main branch the changes will be merged-to the target child branches. We will use an after-check-in trigger.

Trigger workflow

This is how the main method of the trigger code looks:

        static int Main(string[] args)
        {
            try
            {
                TriggerParams parameters = GetExecParams(args);
                ArrayList childBranches = GetChildBranches(parameters);
                MergeToBranches(childBranches, parameters);
            }
            catch (Exception e)
            {
                Console.WriteLine("Error executing trigger : " + e.Message);
            }

            return 0;
        }

These are the parameters we need to run the trigger:

  1. The branch name we want to track for new changes.
  2. A workspace path to issue the Plastic SCM operations.
  3. A file where the trigger output is going to be written.
  4. A mapping file for email notifications (optional).
The last one is optional, but very interesting, since it will allow us to specify a list of branches that we want to set as the destination of the merge-to operation. We can also add emails to notify developers that the branch can't be auto "merge-to" and a manual merge is needed, the file format is "branchName#email". Here is an example: 

...
/main/scm003#iamamaddeveloper@gmail.com
/main/scm004#mlucio@codicesoftware.com
/main/scm005
/main/scm006#theCrazyDev@codicesoftware.com
...

If the merge-to can't be accomplished, an email will be sent if there's any specified for the branch. If no custom branches file is provided, the merge to operation will be applied for all the child branches of the tracked branch.

Results

Here you can see how the automatic merges are done by the trigger:

Branches auto-updated with /main branch changes

And if something can't be merged in an automatic way the developer will receive an email warning about the situation:

E-mail sent by the trigger warning the develop to merge manually the main branch changes

Download

HERE you can download the code. Enjoy it!


Manuel Lucio
I'm in charge of the Customer Support area.
I deal with complex setups, policies and working methodologies on a daily basis.
Prior to taking full responsibility of support, I worked as software engineer. I have been in charge of load testing for quite some time, so if you want to know how well Plastic compares to SVN or P4 under a really heavy load, I'm your guy.
I like to play with Arduino GPS devices, mountain biking and playing tennis.
You can find me hooked to my iPhone, skate-boarding or learning Korean... and also here @mrcatacroquer.

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.

Xlinks and branch per task in a DVCS environment.

Wednesday, June 20, 2012 Pablo Santos 0 Comments

I’m going to tell how we use the Xlinks down here at the Plastic SCM dev team combined with replication.

No surprises if I tell you we use Plastic SCM to handle the plastic development :)

Yes, you know, eating our own’s dog food and all that.

Well, if you take a look at our items view you’ll see something like the following:

This screenshot is coming from my laptop, and I have a server (using SQLite backend) installed on it, and then I push/pull changes from the central.

We’ve 5 main directories and each of them is pointing to a different repository.

  • 01nerva is our main code repository, located at a repo named “codice”. The server code, gui code, plugins, everything is in there. I’ve a light replica with only a few branches and changesets instead of the whole repo on the central server at the office.
  • 02nervathirdparty is our “third party” directory. Libraries coming from external sources, database providers, tools (like nant, ant and many more) live there. It is stored on a different repo, called “nervathirdparty” which is also on my laptop. We use a writable xlink so when we branch on the “codice” repo, if there are changes on this directory, a branch is automatically created and tracked.
  • 03pnunit is the test code. A full repo with “pnunit tests” (PNUnit stands for Parallel NUnit and it is a library we developed years ago and we contributed to the NUnit project. It allows us to coordinate tests among different machines). We use a writable Xlink to this repository, because it is extremely common that a modification on the “codice” repo goes with some code to test it (GUI tests, PNUnit tests and so on).
  • Documentation is a directory pointing to the “doc” repo, which is where the main docs live (test results, schedules, analysis docs, designs and many more). We use a readonly Xlink because we normally use a different workspace to deal with design docs. In fact we only have this one here for testing purposes.
  • Taskdocumentation, again another Xlink. This is a very interesting repo: each time we complete a task, we add screenshots and a short explanation so that the tech writers can use it to document the new stuff. Yes, we could have used an issue tracker for this, a sharepoint server or whatever… but when you develop a SCM… everything looks like a repo :P

    Pulling branches

    Ok, now, as I said I work replicated without direct conn to the central server. So, considering a single task I need to pull can have like 3 associated branches on 3 different repositories… how do I manage to make the replication process simple?

    Look, I have a sync view defined with all the sources (on localhost) and destinations (on Diana). So I update everything, then filter by the branch I want to pull (or push), multiselect on the different repos, and click on “pull branch”.

    And hence I can get all the branches I’m interested on with a single click (or push them!).

    Was it helpful?

    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.

    Browsing remote branches, so great it hurts!

    Thursday, June 07, 2012 Pablo Santos 0 Comments

    I'm going to show you a simple feature that has been there for years but I'm not sure you're all aware of it.

    The scenario

    I'm working on my laptop, and I have a local Plastic SCM server installed on it because I work in a distributed way. I checkin locally and push/pull changes from the company's central.

    Ok, now I need to take a look at an old change that was initially modified on branch SCM9162.

    The problem

    I go to my branch view and try to find the branch filtering the list.

    No luck, the branch is not there.

    Plastic SCM replicas are not full replicas, we do support partial replication, which allows you to create light replicas, extremely convenient.

    But today I'm looking for an old branch that I never replicated to my local repo...

    The solution

    I click on the "advanced" button on the branch view and see the following:

    My current query is looking for the branches with changes in the last 10 days... in my current repo.

    But I can customize the query and search for branches on another repo on a different server!

    Now I get the full list of branches on the central repo on the central server and filter to find the branch I'm looking for.

    The great part is that you can diff the remote branch, which is sorta normal for old centralized SCMs but out of the scope of the modern DVCS... except Plastic! So I go, right click on it, and browse the diff... without having to pull the remote branch to my very clean and small local repo! :)

    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: