Plastic SCM blog

Migrating from SVN to PlasticSCM

2012-02-02T16:29:00.011+01:00

Thanks to the script made by Ignacio Calvo (ignaciocalvo.com) you can migrate your subversion repository into PlasticSCM in a very easy way.

There are a lot of ways to do the same and with different tools, but this one is pretty and quite simple.

You can find the source code here, and a lot of more info in our public forum http://www.plasticscm.net

P4 break

2012-01-27T16:32:00.000+01:00

Are you confined in perforce? Do you want to escape from it?

Materials

We need some tools to success in our adventure!

Python 2.7 (http://www.python.org/getit/releases/2.7/)
P4PythonLib 2010.1 for Python 2.7 (http://public.perforce.com:8080/guest/sven_erik_knop/P4Pythonlib/bin/?ac=83)
Bzr Standalone (http://launchpad.net/bzr/2.4/2.4.2/+download/bzr-2.4.2-1-setup.exe)
Bzr Python Based (http://launchpad.net/bzr/2.4/2.4.2/+download/bzr-2.4.2-1.win32-py2.7.exe)
Git for windows (http://msysgit.googlecode.com/files/Git-1.7.8-preview20111206.exe)
P4-fast-export.py (bzrp4)(http://dl.dropbox.com/u/2974293/trunk.rar)
I assume you have the P4 client and server.

Dangers

It’s not going to be a Boy Scout trip… some brave people failed.

If the Bzr and P4PythonLib is not able to find the Python installation directory please review the following link: (http://selfsolved.com/problems/setuptools-06c11-fails-to-instal/s/63)
If the p4-fast-export.py fails regarding a Git error you have to follow this:(http://stackoverflow.com/questions/5299122/unable-to-import-with-git-p4-on-windows)
The plan

Install all the materials, just install it, you don’t need to open or configure anything.
Place the http://dl.dropbox.com/u/2974293/trunk.rar content inside a directory called “bzrp4” under the "C:\Program Files\Bazaar\plugins" directory, the path to the python migration file should be like this: “C:\Program Files\Bazaar\plugins\bzrp4\p4-fast-export.py”.
Customize the “setup_env.bat” parameters with your environment info, adapt the Git path, P4PORT, and the Perforce server Path. Finally run it.
Open a command line window and run: “python p4-fast-export.py //my/repo/path@all > p4fe.dat”. If you are strong enough you can review the command help. Make sure you are using the Python 2.7 executable.
Create a temporal directory, change your command line directory to it and perform the following: “git init .” “type p4fe.dat | git fast-import” and then “git fast-export --all --tag-of-filtered-object=drop --signed-tags=strip > gitFe.dat”
The last step is “cm fast-import p4ImportedRep gitFe.dat”

If all works fine you will have your repository inside PlasticSCM!!!

Survivors?

CmdRunner power!

2012-01-25T11:30:00.015+01:00

The CmdRunner library is a tiny c# project that allows you to create porcelain applications using the “cm shell” strength.

What is the “cm shell” feature? The “cm shell” utility is able to execute cm commands like flash! It opens a shell interface where you can start issuing cm commands! Test it! first run four or five “cm lrep” lonely commands, not a big deal... Now try to issue “cm shell” and then type lrep & enter, lrep & enter, lrep & enter, lrep & enter... much faster!! ain’t it cool?

Using the CmdRunner library you will be able to use this incredible speed running cm commands and create small or big utilities for your daily work with PlasticSCM.

Let's see some examples, for example, if you want to list all the changesets inside the “default” repository you just need to write something like this:

You can also perform write operations, this example will return 0 or 1 regarding if the checkout operation was successful or not:

After the checkin you may want to modify the file and finally commit it:

You can go further! for example you can create your own c# replication scheduler, launch replication operations is as simple as this:

You only have to surround the cm commands with your stuff and you will able to create everything you can want!!! Every single cm command you can imagine can be executed by our CmdRunner! Some of our plugins are using this library to work! so can create big things!!

You can download the CmdRunner source code and easy examples here: http://www.plasticscm.com/externalcontent/CmdRunnerVS2010.zip

The VisualStudio solution can be opened with VS 2010. The "CmdRunnerExample" project contains code examples to start playing.

Have fun!

More on recursive merge strategy

2012-01-20T00:12:00.001+01:00

A few days ago I had the chance to read a comment on my previous blog post about merge recursive pointing to the Mercurial mailing list where Matt Mackall (of Mercurial fame) strongly criticized my explanation of the recursive merge strategy.

Well, some were simply about the “rendering style” of plastic’s branch explorer (which is what I used to drive the examples), and others about the explanation itself.

Mercurial’s programmer admits that recursive merge is better although argues that it is only worth in some cases and that its costs to implement is bigger than its benefits. Implementing a recursive merge isn’t cheap, as we known down here at Codice, but you know, the big difference between a great product and an exceptional one normally relies on the upper 2% of features that makes it rock.

Today we'll be covering (I'm writing this with the help of Borja, our merge master) "advantages of recursive merge - Case 1: Only one ancestor is the right option".

Back to the drawing board

Recursive merge is not only good for “criss-cross” merge situations but also for more “regular” ones where merge history simply gets complicated.

I’d like to go back to the original example and explain it now in bigger detail:

We’re going to merge from changeset 5 to changeset 6. In this diagram (another explanation using code will come later) we simply say the “content” of the file is A or B or C, but it applies to lines of code (containing important changes, bug fixes and so on).

DAG format

Just in case anyone has trouble understanding that the green lines are merges and they’re rendered from source to destination, here’s an alternative diagram:

Common ancestors

In order to run a merge, you need to identify the “source”, the “destination” and the nearest common ancestor.

In this case the “src” and “dst” are clear but the problem is the “common ancestor” because there’s more than one candidate.

If you look carefully you’ll see that both changesets “2” and “3” can be taken as common ancestors.

A non-recursive merge algorithm will only use one of them, and depending on the “choice”, the result can be quite different.

Selecting “3” as common ancestor

If the algorithm chooses “3” (and as we explained in our previous post, this is the choice taken by Hg, and also would be the one taken by former plastic’s algorithm previous to “merge recursive” implementation) then the following situation will happen:

It will lead to a manual merge, where the user will be forced to choose.

Selecting “2” as common ancestor – the lucky shot

If the algorithm uses “2” as common ancestor, then the merge will be between content “B”, “B” and “C•”, so, since two contributors are the same, the result will be “C”.

It is the expected result as we will see later, and it is a pretty valid choice, the problem is that there’s no good consistent way to choose “2”.

This time, the result matches the expected result, but sometimes it simply leads to an incorrect automatic choice, which is the real problem and the real reason why “recursive” is implemented by git and plastic.

The recursive option

Again, here’s how the “recursive works”: since there’re two ancestors at the same distance, it will “merge them” creating a new virtual ancestor that will be used as the “base” for the final merge between the merge candidates “5” and “6”:

The following image depicts the first step, the calculation of the “virt” common ancestor (the intermediate one):

And then the second step, where the result is calculated automatically, this time without user intervention:

Where is the huge difference?

Comparing recursive and no-recursive algorithms in this example, you might only see that the recursive is able to avoid a manual conflict because it is able to find out how it was solved before. Is it such a big difference? Just avoiding one manual merge?

Real world has the answer: try a "real" merge involving several hundreds of files and then the answer is clear: usable if you don't have to solve the conflicts vs not usable.

Wrap up

We still have a ton of posts to write to share the particular cases where having recursive merge saves the day, so we’ll try to move forward one by one in the coming weeks.

VMware issues when copying virtual machines

2012-01-11T11:24:00.002+01:00

We at Codice Software use internally VMware for testing purposes; specifically we use VMware Server 2 to run automated tests (both smoke, GUI and integration tests) and VMware Workstation for manual testing, support, test new oportunities, platforms, applications and so on.

We've been using this software for several years and we are very happy with it. It performs great, fast, secure and flexible. Nevertheless, sometimes we've encountered some problems. My work as builder of the company includes setting up new testing virtual machines and maintenance, so I'm working with VMware almost everyday.

Recently I created a cloned virtual machine from a snapshot in a VMware Workstation 7. After setting it up I moved it to our automated testing hosts (FYI, we have seven hosts that handles between 5 and 20 virtual machines each, all of them for testing purposes). When I tried to start up the virtual machine in VMware Server 2 I got a crash in the web application that I only could solve by restarting the service in the host machine!

Finally I workarounded the problem doing the following:

First, I created a new virtual machine in VMware server with the same hardware features as the original one.
Edit the .vmx file of the new virtual machine changing it to use the disk files (.vmdk) of the virtual machine I want to register in VMware Server. It's possible to do this from the "New virtual machine" wizard of VMware server or after that by editing the vmx file.
Finally, start the new virtual machine.

This ensures the compatibility with VMware Server.

I hope you'll find this helpful in the future.

Keep in touch.

The history/story behind transparent scm

2012-01-10T10:40:00.000+01:00

I'd like to tell the story of how Plastic evolved towards "transparent scm".What you're seeing today in 4.0 is the result of quite an evolution since we first wanted to walk the transparent path.

Inspiration

Believe it or not, our original inspiration towards transparent scm was good-ol ClearCase. CC implemented MVFS, a dynamic file system able to show you the full file tree of a given version, capture all IO calls and adjust them to SCM operations.

Sample: cat foo.c@main@4

Would be captured by the CC fs driver and instead of issuing a "file not found" it would be able to get the right version of the file to be dumped by "cat".

Likewise it was able to intercept "move" operations so you didn't need to run "cleartool mv" command. What does it mean? You don't need to tell the SCM that you modified a file or that you moved it: it is intercepting all your IO actions, and making the right ops at the FS level!

So, definitely, we always wanted to have some sort "move interception" to avoid having to "tell" plastic a file or dir was moved... it would simply know.

First attempts

We code-named "glass" the first version of what we called "plastic made transparent" (hence glass).

Glass was able to use some underlying FS layer (third party FS driver code to simplify FS creation) to intercept all ops and:

do a checkout automatically when you modify a file (remember, checkout in plastic, perforce or clearcase sense, not svn or git. Checkout means "create a new version" instead of "download the code"

do move ops for you (you just move the files or dirs and glass issues a plastic mv command for you)

deletes and adds elements

Well, writing your own FS is always a cool thing, but there were caveats:

An issue on a FS can tear down the entire system (blue screen of dead ! :P)

Intercepting all the IO ops impacts performance

So, while we used glass internally, we never moved it to production mode.

Xdiff

Ok, you might think: what does Xdiff have to do with transparent?? Well, Xdiff implements an algorithm to find moved fragments of text even when they've been modified afterwards. It is able to calculate "similarities".

Xdiff opened up a new door to make Plastic transparent.

The current version

When we started the development of 4.0 we knew we wanted a new way to deal with local changes:

Work in the workspace doing changes, deletes, adding files or moving them

Have Plastic detect what happened.

And we applied the Xdiff technology. How?

Finding changes, deleted and added elements is easy (just compare disk with the loaded tree)

Each added/deleted pair will be run through a similarity algorithm to check whether it is the same file... moved! The same holds true for directories with a more advanced algorithm.

This way the "pending changes view" is now able to figure out what you did on your workspace, including modified and moved files, and directories (remember dvcs like git or mercurial are not able to track directory renames or moves).

New way or working

Now it is straightforward to work on your favorite editor, doing refactors (renames and moves) and simply switch to plastic to checkin after detecting your changes.

Future

Check http://www.youtube.com/watch?v=cnJ5UgJJSkU. It is a dynamic file system based on Dokan.Net which is able to show a given configuration on a virtual "unit drive".

The evolution of Plastic SCM branches

2012-01-08T19:17:00.000+01:00

A long time ago in a galaxy far, far away.... first level branches were the kings. If you weren’t a plastiker yet then keep on reading because the true story about the empire of selectors is about to be revealed.

All branches were born equal

When the first version of Plastic SCM was up and running (circa February 2006) all branches were “first level branches”. (If you’re interested on Plastic archeology check this http://youtu.be/bn9vc7MRkSQ). There was one branch to “rule them all” which was called “the main branch” which still survives as the ruler of the entire Plastic universe.

The evil empire of selectors

All branches were created equal for a reason: you had your “main” branch, then you added content to it and later you were able to create a new empty “first level branch”. Then, based on selector rules, you were able to specify how to put content on it.

During this old period developers were forced to manually specify how the checkout process was going to happen. Look at the following selector:

repository “coolcode”
  path “/”
    branch “/task001” checkout “/task001”
  path “/”
   branch “/main” checkout “/task001”

Read through it in detail. What does it mean? There are two rules: the first one says: try to load the item from “/task001” and if you’ve loaded the item with this rule and you need to checkout, checkout to “/task001”.

Then there’s a second rule, which is the one performing the branching. This rule will only load items that were not loaded with the first rule (the selector rules are executed in priority order, top to bottom). So, at the beginning items will be on the “/main” branch only, so all will go through this rule.

If you check carefully you’ll see the second rule loads from “/main” but checkouts on “/task001”! This is how branching happened! On checkout, new revisions are placed on the new branch, then the first rule will be able to load them.

Child branches to the rescue

As you can see, all started with really dark days, when just checking out a file forced all poor programmers to remind that “selectors rule”.

Then child branches were born and the following selector:

repository “coolcode”
  path “/”
    branch “/main/task001” checkout “/main/task001”

Was equivalent to the previous one. So, only one rule was needed to specify the “branching behavior” defined before.

A branch like “/main/task001” means: “get the content from task001 but if it doesn’t exist take it from main and place all checkouts in main”. It was an important step ahead back in the day.

The age of smart branches

Later on (circa mid 2008) we launched “smart branches”. Basically to work on a branch you needed to “remember” the “starting point”. If “/main/task001” started from Label BL130 then you needed something like:

repository “coolcode”
  path “/”
    branch “/main/task001” 
      label “BL130” 
    checkout “/main/task001”

Otherwise “task001” would “inherit” from LAST on “main” which was the basis of the powerful “dynamic inheritance feature”.

Smart branches made things simpler because you were able to “set a base to a branch” and then your selector turned out to be something like the following:

repository “coolcode”
  path “/”
    smartbranch “/main/task001”

No need to specify the “label” nor the “checkout branch”.

Branching in 4.0

Branches in 4.0 inherit from “smart branches” but simplify the whole thing: a branch starts from a changesets and upon checkin, adds changes to its initial configuration on the new branch. And that’s all.

Basically, in 4.0 a branch that starts from changest 1024 (on “main”) can be named “main/importantfix” if you want to highlight it is a “child” of the “main” branch, but you can easily create “importantfix” directly from cset 1024 too and they’ll behave exactly the same.

We kept the “child branch” concept in 4.0 because we think it introduces a “branching namespace” which is very good for existing Plastic SCM users (used to it for years) and also good to organize development for newcomers.

But remember that now all branches are equal, independently of whether they’re children or “first level” branches, unlike what happened in Plastic prior to 4.0.

An image is worth…

Listening to the user voice

2012-01-04T21:08:00.000+01:00

Happy 2012 everyone!

You know we listen to you and here’s a blog post focused on explaining what’s new in our latest BL237.7 build (4.0.237.7 version) and where does it came from.Remember we’re using “user voice” and we’re more than happy to receive your feedback there.

The top one request: create branch from my checkouts

You wanted it and here it is the result:

(The entry was introduced in “uservoice” only 20 days ago!)

Gamer’s choice: undo unchanged

I got this one (again) during my “US Tour” about one month ago. Gaming companies seem to dramatically need it, and here it is! :)

Never miss the switch

Another “classic request”: you create a new branch, then you want to switch to it. Why Plastic doesn’t have an option to do it in one step? Ok, here it goes.

More requests

If you check BL237.7 release notes, you’ll find it is filled with requests and fixes. Just to mention a few:

New: Xlink creation from a label. Example: cm xlink codesecondrepo / lb:LB001@second@localhost:8084. I promised this one a few days ago on the forum, didn’t I?

Provide a way to “ignore changes” so that they’re only considered if they’re checked out! (Reminds me Salt Lake City! :P)

Branch explorer label menu: if there’s only one label, don’t show a sub-menu

Merge: able to specify “merge contributor” from a context menu

Merge: able to correctly merge (and visualize!) chmod protection changes

Enhance top level branch creation (top level branches were almost evil in 3.0, but they’re your friends now… I’ll blog about it soon)

New “rm-rep” trigger: new trigger available: before-rmrep and after-rmrep, executed when deleting an existing repository

And fireworks to finish

This one deserves a post on its own: do you know that Visual Studio “move tracking” is greatly limited? If you move a file from one project to another within the same solution… it won’t work. Visual Studio can’t handle this and will incorrectly notify an add/delete pair instead of a move operation to the underlying version control. It was broken for infamous SCC and it is still broken now, including TFS.

Well… we fixed it! New 237.7 is able to deal with files moved between projects!! Cool, isn’t it!

Plastic SCM 3.0 to 4.0 migration notes

2012-01-04T10:01:00.000+01:00

This guide will give you some hints about how to perform a migration from Plastic SCM 3.0 to version 4.0.

Background

Plastic SCM 1.0 was first released in November 2006, and since then the basic underlying design has been evolving incrementally. During the development of version 4.0 we had to make some modifications to the core server structure in order to enable better distributed support, increased performance and an improved merge mechanism.

These core changes didn’t have a huge impact on the underlying database structure (if you look carefully you’ll note that the only difference is about the usage of the old “childrenitem” table, which entries were modified (visible on beta) and now have disappeared completely.

This important change made direct database upgrade (as we always did so far: just run the server and during start-up it upgrades the database) no longer feasible.

On the other hand, we have changed our “import strategy” and instead of developing specific “importers” (Subversion, CVS, Visual Source Safe) we’ve now standardized on the “fast-import / fast-export command suite”. This new “fast-export/import” allows us to provide import capabilities from a wider set of SCMs and also enable an easier “way out” for teams who need to feel they’ve a “way back” in case something fails during the move to a new SCM. It also allows us to provide a much better git interop.

We implemented the “fast-export” support for Plastic SCM 3.0 too (available on the latest releases) and then we’ve just decided to stick to this migration path to enable the move to 4.0.

In short:

Upgrade your 3.0 installation to the latest (3.0.187.33 -> for migration purposes only, don't use it for normal production).

Upgrade your 4.0 installation to 4.0.237.7 (or newer).

Fast-export your repository from 3.0

Fast-import it on 4.0

How to migrate from 3.0 to 4.0

Perform the fast-export of the 3.0 target repository. This command will create a file that will be used by the fast-import. The first argument is the spec of the target repository. The second one is the output file.


$ cm fast-export repo@localhost:8084 repo.fast-export

Perform the fast-import of the exported repository. This command will create a 4.0 database with the imported data (previously exported from 3.0). The first argument is the spec of the target repository (this should be a non-existing repository or a recently created, empty one). The second one is the output file with the 3.0 data.


$ cm fast-import repo@localhost:8087 repo.fast-export

Restrictions due to branch inheritance

There are some important changes between 3.0 and 4.0 underlying structure which will force the 3.0 fast-export command to “discard” some branches.

The reason is tightly related to the way in which 3.0 dynamic branch inheritance worked. In 4.0 each branch points to a changeset “head”, the latest changeset on the branch. So, switching to a branch is always equivalent to switching to the last changeset on the branch. Each changeset is statically resolved which means it simply points to a given source code tree, starting on the root directory of your repository and then to all its content (it doesn’t mean each changeset contains an entire copy of the repo!! Don’t worry about storage!).

Things were a little bit different with 3.0, where the selector rules were necessary in order to resolve a given tree. Remember you could have branches pointing to “last” which means switching to it would load your content on the branch and “combine it” (not merge, just combine the non-overlapping entries) with the latest on the parent branch.

There is a big difference between the changesets in 3.0 and 4.0. In 4.0, each changeset points to an entire, statically resolved tree. It wasn’t true in 3.0 for the changesets on branches inheriting from “last” since “last” would dynamically move.

What does it mean? Basically: branches inheriting from “last” won’t be exported by the 3.0 fast-export command and hence won’t be imported in 4.0. If this is a problem for you and prevents you to migrate to 4.0, please let us know.

Merge tracking changes

Merge tracking has been deeply modified in 4.0. Merge tracking was implemented at the “item” level prior to 4.0 and has now been moved to “changeset” level.

Item level merge tracking: means that each time you merge a file or directory, there’s a new merge link created between the specific file or directory revisions. It provides some advanced functionalities (like partial merging: you can merge just part of a changeset and then merge the rest later keeping full tracking) but paying a high price for it: performance is poorer. Each item has its own “merge tree” that needs to be calculated and checked individually. Merging a big number of items tends to be slow.

Changeset level merge tracking: means that the merge links are created between changesets instead of items. (Note: this is the way in which all the new DVCS work: Git, Hg, Plastic SCM…). Performance is much higher since merge calculation doesn’t depend on the number of items to be merged. Understanding the evolution is also simpler because you only have to take a look at the branch explorer to understand what was merged and what was not, instead of having to check each item individually. In 4.0 we didn’t only modify the “tracking” but also greatly improved the underlying merging mechanism supporting many merge cases that were simply not doable before (divergent move, change-delete conflicts and many more).

This important structural changes (tree + merge tracking) are the reasons why a “direct” migration wasn’t feasible so far, and also the reason why we decided to go through a “export-import” path.

The main risk migrating from 3.0 to 4.0 (and we’re currently working on it) is when a “partial merge link” is wrongly migrated as a full merge link (the only ones supported in 4.0) leading to potential merge calculation errors later on.

Merge between branches with different bases

Check the following merge scenario created with 3.0:

The merge from /main/task001 to /main/task002 will only propose /src/foo.c to be merged, because it was the only item modified in the branch. It means that “/doc/plan.pdf” won’t be proposed to be merged to “task002”. This was an important limitation on 3.0 and has been fixed in 4.0.But, if the merge was performed in 3.0, the merge link will be there but “task002” won’t contain the modified “plan.pdf”.

Now you migrate from 3.0 to 4.0 and decide to merge “task002” to “main”. The new merge system will check the differences between the source changeset and the base changeset and it will find that “plan.pdf” was modified (because “task002”, despite of the 3.0 merge, will still contain the “old plan.pdf”, and 4.0 doesn’t have (so far) a good way to know whether it was incorrectly merged on 3.0 or really modified.

At the end of the day, merging task002 will put the old “plan.pdf” on “main”, incorrectly, because the merge link between task001 and task002 is set by 3.0, and 4.0 can’t handles merge differently.

(The case is a little bit dense so feel free to contact us if you need further info).This is not a problem with the following type of merges:

It has been detected as branch rebase (the base of the branch was changed by the switchbranchbase command).

The source and destination of the merge are in the same branch.

The source of the merge is the main branch.

The destination branch of the merge is the branch base of the source branch.

The source branch of the the merge is the branch base of the destination branch.

The source & destination branches have the same changeset/label as branch base.

Active Directory - Work with huge AD trees

2011-12-30T10:53:00.009+01:00

Recently we have experienced an issue when configuring the system authentication mode to Active Directory. The Active Directory tree contained more than 3000 entries.

By default, Active Directory allows fetching only 1000 entries foreach search request to the Active Directory Domain. The main reasons of this limit are security and performance.

If a search query to the Active Directory returns more than 1000 results, the ActiveDirectory throws an exception (sizelimitexception, LDAP error code 4).
Plastic SCM catches the exception and shows the following warning message:

At this point, there are three possible solutions to get a result:

Close the warning message and specify a filter on the "Filter" textbox from the User Selection dialog.
Doing this, Plastic SCM will filter the query to the Active Directory domain, and will retrieve less results than before.

Constraints:
- The specified filter has to return less than 1000 results.
Specify a subdomain to the PlasticSCM server configuration instead of the entire Active Directory domain.
Doing this, Plastic SCM server will query only for users and groups from the specified subdomain.

Example:
If you currently have configured your PlasticSCM server ActiveDirectory's domain to:
"mycompany.com" (or "dc=mycompany,dc=com")
Change it to:
"developers.mycompany.com" (or "dc=developers,dc=mycompany,dc=com")
You can perform this change through the server configuration wizard.

Constraints:
- All the PlasticSCM users must be contained on that subdomain
- The list of users/group on the subdomain contains less than 1000 entries.
Change the Active Directory's limit. You can do that by following this guide from Microsoft's Knowledge base: http://support.microsoft.com/kb/315071
(Sections: "Starting Ntdsutil.exe", "Viewing current policy settings" and "Modifying policy settings").

Mainly, the steps are the following:
- Run "Ntdsutil.exe" on the Active Directory machine.
- At the "Ntdsutil.exe" command prompt, type "LDAP policies"
- At the "LDAP policy" command prompt, type "connections"
- At the "server connection" command prompt, type "connect to server MYHOST.mydomain.com"
  Examples:
  "connect to server localhost"
  "connect to server ldapserver.archgroup.com"
- At the "server connection" command prompt, type "q"
- At the "LDAP policy" command prompt, type "Set MaxPageSize to NEW_VALUE"
  Example:"Set MaxPageSize to 3000"
- At the "LDAP policy" command prompt, type "Commit Changes"
- At the "LDAP policy" command prompt, type "q"
- At the "Ntdsutil.exe" command prompt,type "q"

Move detection – advanced bits

2011-12-21T03:16:00.000+01:00

Move detection is one of the big features in 4.0, as I’m sure you’re already aware of.

It has been implemented on top of the same underlying technology we use for Xdiff and Xmerge.

The point is: you just move a file on your workspace without issuing a “cm mv” operation (command line, GUI or through a plugin), and later Plastic is able to “detect” the move happened.

How it works

The principles of move detection are quite easy: Plastic has a list of the files (stored under .plastic/plastic.wktree file on the workspace) that are “controlled” under the workspace. Then you decide to look for changes:

If a file on the workspace is not on the list: then it is proposed as an “added” candidate

If a file is on the list but not on the workspace: then it is proposed as a “deleted” candidate

How the “moves” are detected? The “added candidates” are matched with the “deleted candidates” and if they’re “similar enough” then they’re proposed as “moved”.

Let’s make it more complicated

What if foo.c is something like the following?

And we rename it to bar.c and modify it this way:

The file was so small that this little change will make the two versions less than 90% different, so “pending changes” view will look like this:

As you can see plastic detects a “potential add” and a “potential delete”.

Matching manually

Right click on the “potentially added” file and select “search matches”:

And then the “matching” dialog will show up. You can slide the similarity bar until the candidate appears:

And once you “accept the selected match”, the “pending changes view” will reflect the move:

plastic 700 sec – git 1200 sec – a c# development story

2011-12-09T18:33:00.000+01:00

The short story: take a code tree of 192.818 files in 33.877 directories (overall size: 5.75GB) and check in on your favorite version control tool. Plastic SCM needs 713 secs, Git needs 1287 secs.Yes, we’re faster than Git!!!!!!And yes: a C# program can outperform a well-written C program by a 44%!!!(Ok, we’d be running cycles around “gitty” had we chosen C++ :P)

The story – the beginning

We started plastic scm back in 2005 and we decided to go for C# because it was much faster to develop with than C/C++. I missed C++ for a while but “.net remoting” (I was a DCOM fan) changed my mind.

We only used C# because Mono existed. A true SCM must be multiplatform. Mono was there, so we went for C#.The first time we added a source tree to plastic was in September 2005 or so. It was the quake source code: 1200 files (about 30Mb). It took 11 hours to complete. (Yes, you read correctly, eleven hours!!!)

Then we removed NHibernate out of the picture and developed the “sql” datalayer (look for datalayersql assembly when you download plastic) we’re still using today (with a ton of improvements) and things started to speed up.

We released Plastic SCM 1.0 back in November 2006 in TechEd Developers in Barcelona. It wasn’t the fastest thing on earth but it already had some of the best branching and merging in town. (Check this for some historical plastic scm photos)

You’ve to pay for your mistakes

And we did. The first thing was the design of the “communication layer” between the client and the server. We came up with a neat and supposedly well designed set of interfaces. Thanks to Mono.Remoting it was all like “invoking local methods”. Isn’t it good?

NO.

Interface Oriented Design greatly explains why.Initially (for newbies) it can sound much better to have something like this:


CheckinInterface
{
    void Checkin(File file);
}

Than this:


CheckinInterface
{
    void Checkin(File[] files);
}

But it is simply wrong. Over the network, the less roundtrips, the better.

Of course it wasn’t as simple as that, it meant really redesigning most operations to work “block based” instead of individually, something we finally put on stone back in Nov 2010 when we started Plastic SCM 4.0.

Now every data transfer is minimized (and there’s still work to do) and ready to work with “bulks”. So, the bigger the checkin op is, the faster we are compared to other systems out there.

Being faster than Git

At the beginning we wanted to be faster than Perforce and so we did: our “update” (downloading the code to a workspace, “checkout” in git/svn jargon) was faster than competitors long ago.

But, the folks at Perforce removed their “fast scm motto” once Git became mainstream (now they’re on a different party) and beating Perforce wasn’t fun anymore.

We focused on scalability due to business requirements for a while() and we still do! But beating all competitors on a single “speed up” test was sort of a goal.

Changes on the database backend

Plastic stores all data and metadata on a database: it can be MySql, Firebird, SQLServer, SQLServer CE, Oracle and now also Postgresql.

In order to speed up we had to dramatically reduce the number of data transfers to the database. In SQL Server we did that using “bulk copy” selectively when possible (a huge checkin will activate it), so 8 months ago we were consistently beating git with the same data tree using SQL Server…

Yes!! It is possible to insert a tree of 200k items on SQL Server (using the network stack and everything) than putting it on git’s hidden directory (ok, database :P).

The current test

The current test I’m writing about today was performed using:

Plastic 4.0.237.2 (sqlite backend)

git -> 1.7.8.msysgit.0

We’re running on Windows 7 on a DELL XPS 13 laptop (2/3 years old) with 8GB RAM.

We’re using the sqlite backend, which is very good for distributed usage (I’m using it for more than 2 years now on my laptop) but doesn’t work well with concurrency.

Future steps

We always wrote our data and metadata on SQL databases. They work simply great, even faster than the file system (http://codicesoftware.blogspot.com/2008/09/firebird-is-faster-than-filesystem-for.html) under certain circumstances.

But we’re considering a file system based backend (custom, closed, sort of what git/hg do today) to be used by distributed developers (main server can still be on SQL Server or MySql) and speed up some operations even more… (if possible! :P)

How to link repositories using Xlinks

2011-12-01T14:46:00.016+01:00

Xlinks are one of the coolest new features in Plastic SCM 4.0.

They're basically a way to link different "trees" together so that a "project" repository can have "versioned links" to other component repositories and then just switching to a branch on the "project" repo will set up all the code for you.

For 3.0 users: instead of delving with complex multi-repository selectors, Xlinks enable a way to just link to repos and download them easily (developers on your team won't have to copy/paste complex selectors, just switch to the right branches).

For Git users: Xlinks are "submodules" done right!

I’m going to show you how easy is working with multiple repositories at the same time using Xlinks.

Scenario

We have several repositories, one for the source code, one for marketing stuff and the last one for third party tools.

Core

ThirdParty

Marketing

Motivation

It’s a good idea to have your information divided into isolated repositories since they are independent sub-projects, but actually they are part of the same project, so many times they will need to evolve together and share their content. For example, the Core repository needs the ThirdParty repository to achieve a successful build.

How can we mix these repositories and work with all of them at the same time? Xlinks.

Solution

We have to create a new repository that will be the one who is going to manage the Xlinks to external repositories. This will be our “Project” repository.

Create a new workspace working against the new repository, make three new directories, this will be the skeleton for the final structure.

Now we create the Xlinks to our external repositories. You can find more info about how to create them issuing “cm xlink --help” but basically you just need to type ‘--w’ if you want to create a writable Xlink, where is going to be placed the external repository content, the external repository path that is going to be mounted and finally the starting changeset of the external repository.

Sub-root paths will be supported in the future but from now you can only use the root path “/”.

Now checkin ‘em all!!! You can use the pending changes view to do it.

When everything is inside the repository your Items view will be like image below, notice the small arrows over the icon means that they are Xlinks to external repositories.

The last step to finally get the external content is perform an update operation, you can do it by right clicking on the workspace root item and Update.

One repository to rule them all, One repository to find them.
One repository to bring them all and in the darkness bind them.

Extra bonus

Do you remember that we created the Xlink with the “--w”? That means that they are writable! You can modify items under an Xlink, remove, move, merge, create branches, basically EVERYTHING.

With writable Xlinks you can evolve the 4 repositories at the same time, try to create a new branch on your Project repository, switch to it. Checkout a file inside an external repository, modify it a little bit and finally checkin it. PlasticSCM will automatically create a new branch on the remote repository to keep the change done! And you don’t have to care about nothing it simply works!

How to install Plastic SCM 4.0 without system requirements restrictions

2011-11-30T14:06:00.004+01:00

Hi, all:

As you might already know, Plastic SCM 4.0 comes with SQLServer CE 4.0 as the default backend in Windows. We decided to replace our good-old friend Firebird with this one to avoid undesired collisions with existing Plastic SCM 3.0 installations, since Plastic SCM 4.0 uses a different database schema that is not directly upgradeable.

On the other hand, Plastic SCM 4.0 minimum software requirements have been lifted to meet those of SQLServer CE 4.0 (check this link: http://www.microsoft.com/download/en/details.aspx?id=17876#system-requirements), which is a bit annoying, specially if you will customize your db.conf file to use a different backend after the installation / upgrade process.

Strictly speaking, Plastic SCM 4.0 requirements still are .NET Framework 2.0 SP2 for the server and .NET Framework 2.0 for the client (we finally moved our client to .NET Framework 2.0, hurray!), so if you want to avoid all the system requirements just open a CMD console (or shell in Linux) and type the following in a single line:

PlasticSCM-4.0.xxx.yyy-windows-installer.exe --nocheckrequirements true

where xxx.yyy is the release number you are trying to install. Please, take into account that if the system requirements are not met, Plastic SCM may not work correctly.

Thanks for reading and enjoy Plastic SCM 4.

4 3 2 1... launch

2011-11-24T00:32:00.001+01:00

It has been an hectic season but we made it and released 4.0 last 17th.There has been several great things, but look at the videos: we had Robert C. Martin (of CleanCode and CleanCoders fame) and Steve Berczuk (THE Branching Patterns book) as keynote speakers!! Awesome, isn't it?http://www.plasticscm.com/plastic4launch/index-4.htmlNow looking forward talking, blogging and "demoing" the new release to the world! :)Thanks everyone for your support so far. We're a small, highly committed team achieving great things! :) Thanks!

Git merge vs the world

2011-11-17T17:37:00.001+01:00

I’ll be talking about git merge system again, one of the strongest on the planet, and how a good merge system can unlock a new world of possibilities for developers facing complex refactors.And then, I’ll tell you how to break it. And what can be done.

Refactor and merge

What does refactor have to do with merge? Aren’t merging and refactors on different planets?

Not at all: you’re working on a refactor and then you need to move Class.java to a new package. It happens, doesn’t it?

But while you’re working on your refactor, I’ll be tweaking Class.java.

Ok, now refactor has to do with merging, and if you’re avoiding this situation it only means one thing: you don’t have a proper SCM (we could argue but, ok, tell me you do not need a mouse, a good IDE…).

The good, the bad and the ugly

Now you’ve to merge the previous scenario. What will happen?

Git (and of course my beloved Plastic SCM) will do the right thing: you get the rename plus the change. This IS what you expect.

SVN and the old fashioned pack (the bad and ugly) will, at best, end up with two files: the “old” Class.java with my changes plus yours, without my changes, on your destination location. Crazy.

Let’s break it

Let’s do something else: you move and modify Class.java. But I do the same… moving it (of course!) to a different location.

Don’t do this at home with SVN: ok, the movie is over from the non-dvcs/non-merging scms, let’s focus on the real mergin machines.

Git it!

How does Git handle it?


$ git commit -a -m "initial"
Created initial commit ced4e21: initial
 1 files changed, 181 insertions(+), 0 deletions(-)
 create mode 100644 foo.cs

$ git branch task001
$ git checkout task001
Switched to branch "task001"
$ vi foo.cs
$ git mv foo.cs bar.cs
$ git commit -a -m "change on task001 + rename"
Created commit d3c6970: change on task001 + rename
 2 files changed, 181 insertions(+), 181 deletions(-)
 create mode 100644 bar.cs
 delete mode 100644 foo.cs

First move and change, let's go to the second.


$ git checkout master
Switched to branch "master"
$ vi foo.cs
$ git mv foo.cs moo.cs
$ git commit -a -m "change on master + rename"
Created commit 4644cb7: change on master + rename
 2 files changed, 182 insertions(+), 181 deletions(-)
 delete mode 100644 foo.cs
 create mode 100644 moo.cs

$ git merge task001
CONFLICT (rename/rename):
Rename "foo.cs"->"moo.cs" in branch "HEAD" 
rename "foo.cs"->"bar.cs" in "task001"
Automatic merge failed; 
fix conflicts and then commit the result.

Ok, git nows about but... how does it handle it?


$ git status
# On branch master
# Changed but not updated:
#
#       unmerged:   bar.cs
#       unmerged:   foo.cs
#       unmerged:   moo.cs
#       modified:   moo.cs
#

no changes added to commit

$ ls
bar.cs  moo.cs

Ooooops! The files are not merged and you’ve to solve the conflict yourself!!!

Plastic it!

Is there a better way?

Yes: the dvcs should:

ask you: which rename do you prefer? (or any other option)

help you solve the rename

merge the files

And that’s what Plastic SCM does.

I’m happy to say that we’re launching Plastic SCM 4.0 today at www.plasticscm.com/launch... Join now! Superheroes already did http://plasticscm.com/heroestalk

Connecting Plastic SCM to github

2011-10-05T16:01:00.000+02:00

We’ve taught Plastic SCM to speak the 21th century SCM “lingua franca”: fast-import format as defined by git here.What does it mean? First, it means you can import or export a repo from git (so, an easy way to try and move to Plastic SCM, while keeping a safe exit for the non-believers!).Since almost anything out there is able to be exported to “fast-import” format… it also means you can easily move to Plastic SCM from CVS, SVN, Git, Mercurial, ClearCase, Perforce… anything!

Import a repo from github

First things first: how do you import from github?

Suppose you want to import the following repo: git://github.com/twopointzero/NUnit.git

First you clone it locally:

$ git clone https://github.com/postmodern/ronin.git

Then you fast-export it:

$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip >   repo.fe

And now you go and import it to plasticscm:

$ cm mkrep myrepo@localhost:8084 (optionally create a new repo!!!)
$ cm fast-import myrepo@localhost:80804 repo.fe

And you’re done! Open the branch explorer in Plastic and... :)

Export from Plastic SCM

We’ve also implemented the “fast-export” command so exporting is as easy as:

$ cm fast-export myrepo@localhost:80804 repo.fast-exported

And again… you’re done!

Incrementally synching with git

What if you needed to work “incrementally” with git from Plastic SCM?

Such as the following:

Basically, you’ll need to take advantage of the incremental import/export provided by the fast-import/fast-export toolset using “marks”.

The following diagram depicts the process and shows the commands :

Initial export from git to plastic

Create the package on git

$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip \
         --export-marks=marks.git  > repo.fe

And get it imported in Plastic SCM

$ cm fast-import repo@localhost:80804 repo.fe \
        --export-marks=marks.cm

Make some changes on plastic and send them back

Send them back to git:

$ cm fast-export repo@localhost:80804 repo.fe.00 --import-marks=marks.cm --export-marks=marks.cm

And import them in git:

$ cat repo.fe.00 | git fast-import --export-marks=marks.git  --import-marks=marks.git

More changes now from the git side and back to plastic

$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip \
         --export-marks=marks.git --import-marks=marks.git > repo.fe.01

$ cm fast-import repo@localhost:80804 repo.fe.01 \
     --import-marks=marks.cm --export-marks=marks.cm

Please note we’re always using the files “marks.cm” to hold the import/export marks from Plastic SCM and the file “marks.git” to contain the ones from git.

The “packages” have been named repo.fe first then the second is repo.fe.00 and repo.fe.01eventually.

The process can go on and on n.

Limitations

By using “fast-import/export” there’s one limitation you must keep in mind: concurrent changes are not allowed.

I mean: if you make changes on “master” and at the same time you make changes on the corresponding “/main”, the system won’t be able to deal with it!

The current solution is able to handle the scenario if you make changes at one side at the time.

Using feature branches, for instance, get rids of the potential collisions anyway.

What else is there in 4.0?

We’re currently working on “cm sync” the command which will be the “equivalent” to “git svn dcommit” and hence we will be able to deal with sync concurrent conflicts in git, svn and tfs.

How to get this??

What to try this? Go to http://www.plasticscm.com/labs/40-beta-1.aspx and download the 4.0 beta! :P

work in progress: bidirectional sync

2011-10-02T01:56:00.000+02:00

I'm working on "bi-directional sync" which is one of the reasons behind the move to Plastic SCM 4.0.

What is it?

Simple: a way to sync a branch with another scm and handle conflicting changes.

I'm writing down a very initial session below:

Sync with Subversion - initial import

Here we go, first thing is to make myself admin of the repo due to a bug I still didn't fix on the import code (ouch!)


  $ cm setowner -user=pablo repserver:localhost:8084

Now launch the first sync, note I specify the branch in Plastic, the type of scm (svn, it could also be "tfs" now) and the scm url


  $ cm sync main@default@localhost:8084 svn svn://localhost
    Latest cset on foreign SCM: 6
    Changesets to pull
    1 - 01/10/2011 7:18:16 -  - trunk created
    2 - 01/10/2011 7:19:30 -  - initial code import
    3 - 01/10/2011 7:28:25 -  - hud.txt modified
    4 - 01/10/2011 7:30:28 -  - trunk created
    5 - 01/10/2011 8:00:04 -  - hello.txt added
    6 - 01/10/2011 8:03:00 -  - modified hello.txt

Now a second hack due to another bug I still didn't fix


  $ cm au pablo
    User pablo has been successfully activated

Then create a new workspace, update to get the code imported from SVN and so on


  $ cm mkwk plasticwk .
    Workspace plasticwk has been correctly created

  $ cm update .
    Copied c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\hello.txt

   $ cm ls
            01/10/2011 08:03 dir    br:/main#6         .
            01/10/2011 08:05 txt    br:/main#1         hello.txt

Make a change in Plastic and push it to SVN

Create a new file, checkin and push to SVN.


   $ echo bye > bye.txt

   $ cm add bye.txt
    The selected items are about to be added. Please wait ...
    Item bye.txt was correctly added

   $ cm ci -c="added bye.txt"
    The selected items are about to be checked in. Please wait ...
    Assembling checkin data
    Validating checkin data
    Uploading file data
    Uploaded 6 bytes of 6 bytes (100%)
    Confirming checkin operation
    Modified c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk
    Added c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\bye.txt
    Created changeset cs:7@br:/main@rep:default@repserver:TRISKELION:8084

Now launch the sync, please note I don't have to specify the type of remote scm anymore, and I don't have to type the svn url either because it gets "saved" after the first sync.


  $ cm sync main
    Last equivalence found 6 -> 6
    No new revisions to pull from the foreign SCM
    Changesets to push
    7 - 01/10/2011 8:06:19 - pablo - added bye.txt
    Check commit
    Committed changeset 7

Launch the sync again and it tells there are no changes to push or pull anymore.


   $ cm sync main
    Last equivalence found 7 -> 7
    No new revisions to pull from the foreign SCM
    Branches are in sync. There are no changesets to push or pull

Concurrent change scenario

Now, the guy at the plastic and the svn sides make changes concurrently, what will it happen? Let's go.

Add a new file in plastic:


   $ echo newest > newest.txt

   $ cm add newest.txt
    The selected items are about to be added. Please wait ...
    Item newest.txt was correctly added

   $ cm ci -c="added newest.txt on plastic"
    The selected items are about to be checked in. Please wait ...
    Assembling checkin data
    Validating checkin data
    Uploading file data
    Uploaded 9 bytes of 9 bytes (100%)
    Confirming checkin operation
    Modified c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk
    Added c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\newest.txt
    Created changeset cs:8@br:/main@rep:default@repserver:TRISKELION:8084

Now we modify a different file in SVN, ok?

I launch the sync again, read the details


   $ cm sync main
    Last equivalence found 7 -> 7
    Latest cset on foreign SCM: 8
    Changesets to pull
    8 - 01/10/2011 8:08:12 -  - =modified bye.txt on svn
    Changesets to push
    8 - 01/10/2011 8:08:24 - pablo - added newest.txt on plastic
    There are changesets to push and pull.
    Will pull the remote changes then you'll have to merge them and push the changes back.

What happened?


   $ cm find changeset
    10       0        /main                01/10/2011 08:04:35 all      default Root dir
    20       1        /main                01/10/2011 07:18:16 pablo    default trunk created
    4348     2        /main                01/10/2011 07:19:30 pablo    default initial code import
    4367     3        /main                01/10/2011 07:28:25 pablo    default hud.txt modified
    4379     4        /main                01/10/2011 07:30:28 pablo    default trunk created
    4384     5        /main                01/10/2011 08:00:04 pablo    default hello.txt added
    4388     6        /main                01/10/2011 08:03:00 pablo    default modified hello.txt
    4397     7        /main                01/10/2011 08:06:19 pablo    default added bye.txt
    4405     8        /main                01/10/2011 08:08:24 pablo    default added newest.txt on plastic
    4410     9        /main                01/10/2011 08:08:12 pablo    default =modified bye.txt on svn

    Total: 10

The "remote" changeset from SVN has been pulled but since there's a conflict, I'll have to merge before pushing back to svn.


   $ cm merge cs:9
    The file /bye.txt#br:/main#1 was modified on source and will replace the destination version

   $ cm merge cs:9 --merge
    The file /bye.txt#br:/main#1 was modified on source and will replace the destination version
    Merging c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\bye.txt
    The revision c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\bye.txt@9 has been loaded

   $ cm ci -c="merged from cs9 coming from svn"
    The selected items are about to be checked in. Please wait ...
    Assembling checkin data
    Validating checkin data
    Uploading file data
    Confirming checkin operation
    Modified c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk
    Copied c:\Users\pablo\wkspaces\testwkspaces\svnsync\plasticwk\bye.txt
    Created changeset cs:10@br:/main@rep:default@repserver:TRISKELION:8084

Now I run the sync again. Plastic is going to push the new cset (the merged cset) that will contain the changes between the merged cset (10) and the imported cset from svn (9) hence the changes introduced in 8.


   $ cm sync main --preview
    Last equivalence found 9 -> 8
    No new revisions to pull from the foreign SCM
    Changesets to push
    10 - 01/10/2011 8:09:58 - pablo - merged from cs9 coming from svn

   $ cm sync main
    Last equivalence found 9 -> 8
    No new revisions to pull from the foreign SCM
    Changesets to push
    10 - 01/10/2011 8:09:58 - pablo - merged from cs9 coming from svn
    Check commit
    Committed changeset 9

Now, how does it look like from the SVN side?


   $ svn diff -r 9:8
    Index: newest.txt
    ===================================================================
    --- newest.txt  (revision 9)
    +++ newest.txt  (revision 8)

The file "newest.txt" was added on changeset 8 in Plastic and is now in SVN!Great, isn't it? I expect to get it merged asap into the next 4.0 beta release.

Merge recursive strategy

2011-09-27T17:12:00.001+02:00

You’ve must heard about “git merge recursive strategy” which is the default algorithm that git uses when merging two branches.How does it work and why is it good?

Basics – elements on a merge

You’ve got two branches you want to merge. The basic “players” to consider are:

The “source”: the changeset you’re merging from. Changeset 16 in our sample below.

The “destination”: the changeset you’re merging to. 15 in our case.

The “ancestor”: the changeset (or commit) which is the nearest parent of the “source” and the “destination”, which is “10” in our case.

So, we will merge 16 and 15 using 10 as ancestor. We DO need an ancestor to be used in “three-way” merges (more about it here).

When is “merge recursive” needed?

But, sometimes the scenario is not that simple. What if we find “two common ancestors”? The picture below shows how in this example we have to possible “common ancestors”.

Please note: the example is a little bit forced since there’s not a good reason (initially) for the developer merging from changeset 11 into 16 instead of merging from changeset 15 (the latest from the branch “main” at the point of the merge). But let’s assume he has to do it for a reason (like cset:11 was stable and 13 and 15 weren’t at the time, for instance). The point is: between 15 and 16 there’s not a single unique ancestors but two ancestors at the same “distance”: 12 and 11.

While it won’t happen on a daily basis, it is really likely to happen with long lived branches or complex branch topologies (the case depicted above is the shortest one driving to the “multiple ancestor” problem, but it can happen too with several changesets and branches in between the “crossed” merges).

One solution is to “select” one of the ancestors as the valid one for the merge (which is the option Mercurial takes) but as we will see below, it has many drawbacks.

How “merge recursive” works?

When more than one valid ancestor is found, the “recursive merge” strategy will create a new unique “virtual ancestor” merging the ones initially found. The following image depicts the algorithm:

A new “ancestor 2” will be used as “ancestor” to merge the “src” and “dst”.

The “merge recursive strategy” is able to find a better solution than just “selecting one of the two” as I’ll describe below.

Why merge recursive is better – a step by step example

Let me use the following “notation” in thenext example: a file “foo.c” with three lines like these:


b
c
d

It will be described as: /foo.c = bcd.

Of course, for the sake of simplicity I’ll be using “stupid lines” like “abc” but assume the example is valid for real code too.

Let’s take a look at the following case in the diagram below:

I’ll try to describe it changeset by changeset:

0 -> we had a file foo.c with content foo=bcd (three lines, first is “b”, second is “c” and third is “d”)

1 -> we edit foo.c on a branch and add a new line so it ends up being foo=bcde

2 -> we modify the second line of the file on “main”. Now the file is foo=bCd

3 -> we create a new branch from cset “2” and add a new line at the beginning so it is now foo.c=abCd

4 -> going back to “task001” we modify the line we just added: foo.c=bcdE

5 -> we “undo” the change we just did on “main”: foo.c=bcd

6 -> we MERGE “4” and “3” and create “6” as foo.c=abCdE (we combine the changes we made on “task002” (adding a new line at the beginning) with the ones in “task001” (adding “E” at the end) and also the change coming from “2” on /main.

7 -> we now MERGED “4” and “5” introducing the change from “4” (last line added) into “main”: foo.c=bcdE

If we now merge “task002” on “main” (cset “7” and cset “6”) what should we get?

We should get the “addition” on “task002” (a new line “a” at the beginning) on top of “7”, isn’t it?

The expected result is: foo.c=abcdE.

We shouldn’t get the line “C” in uppercase as it is on “task002” because we fixed it afterwards on “main”.

As you can see on the diagram, I highlighted the changesets “4” and “2” because they’re the two possible common ancestors from “6” and “7”.

Which one should be choose?

Mercurial will choose “4” because its algorithm chooses the “deepest” ancestor in case that more than one is found.

What happens if we choose “4”?

We will merge 4=bcdE, 6=abCdE and 7=abcdE and the automatic result (by any 3-way merge tool will be):

First line -> a (it’s there on 6 and 7)

Second line -> b (it’s there on the three contributors)

Third line -> C (changed on “6” but unchanged on “4” and “7”)

Fourth line -> d (unchanged)

Fifth line -> E (unchanged)

So, we automatically get foo=abCdE which is WRONG!!

We took “C” instead of “c” due to the wrong ancestor selection.

How recursive merge fixes the mess?

As I described above, the first thing “recursive merge” is going to do is to calculate a new “virtual ancestor” merging “4” and “2” as the following picture shows:

The result “cset X” is foo=bCdE.

Later, “cset X” is used as the “ancestor” of “6” and “7” and then we get:

Ancestor: foo=bCdeE

Source: foo=abCdE

Destination: foo=bcdE

Result: foo=abcdE -> which is what we were looking for!

The calculated result takes into account the “fix” done in changeset “5” and hence the result is correct!

Why it is so good?

If you have to deal with branching and merging and you don’t have a good merge algorithm, you can end up with broken files without notice!

In short: Git will do it correctly, Hg will break the result, and SVN and others will simply mess up the whole thing.

In Plastic SCM 4.0 we’ve also implemented “merge recursive” algorithm, so we are able to produce the same result (in fact, our algorithm is even more powerful, handling correctly cases that even Git is unable to deal with successfully).

More cases

I focused on “file conflicts” today but it is easy to come up with examples affecting directory structures too. I’ll cover it in a follow up blog post.

Wrapping up

Branching and merging are the two weapons you must have in your developer’s toolset… but make sure you have the best possible ones, the ones that really do the job.

Plastic SCM release 3.0.30

2011-09-16T16:45:00.012+02:00

It has been a while announcing a blogpost for new 3.0.xx release, however, we have been releasing a bunch of them with bug fixes and usability improvements, and this one will highlight the most important bullets in the current release Plastic SCM 3.0.30.

Full release notes: http://www.plasticscm.com/download/releasenotes.aspx

Download page: http://www.plasticscm.com/download/login.aspx

Third party integration matrix list: http://www.plasticscm.com/infocenter/third-party-compatibility.aspx

New features:

Atlassian Bamboo integration:

Plastic SCM now integrates and includes a plugin to integrate with Atlassian Bamboo Continues Integration (http://www.atlassian.com/software/bamboo/)

Zutubi Pulse:

Plastic SCM plugin is updated to support Zutubi Pulse 2.3

Eclipse plugin:

A checkbox has been added to include changed items on the sync view and the commit dialog.

Mergetool standalone:

A request from our Plastic SCM community to add Drag&Drop into our mergetool.exe when executed as a standalone diff / merge tool.

Filtering dialog Cloacked / ignored is sizable:

Now the dialog is sizable, so users can see long rules.

Support for big files > 2 Gb

When a user checked in a file bigger than 2GB, the update failed. It did not download the entire file. There was an overflow with the size of the file.

Improvements and bug fixes (only most important mentioned below):

Visual Studio integration:

The Plastic SCM plugin for visual studio has been reviewed a couple of time since we discovered that the support for solution folders added in release 3.0.19 needed to be revisited.

Duplicate project entries in Pending changes view.

Duplicate solution files .sln in Pending changes view

Fixed an invalid cast exception when trying to select items in the Solution Explorer of Visual Studio 2010. This bug happened occasionally.

When having a Windows Presentation Foundation project some checked-out files were not shown in the Pending changes view. The offline checkouts were not restored when Visual Studio was restarted.

SQL server database backend:

If during a label application a SQL command timeout fires, the rollback operation was not correctly performed, It could cause inconsistency in the databases between the tables marker realizations and object table.

Installer for MAC:

There was a problem when trying to start up the server in some configurations, related to the setup of the /Library/Startup directory.

Installer for Plastic SCM Proxy:

Proxy installer: problem solved related to a library not included in the installer.

Plastic SCM Client / server version check:

Compatibility check between client and server was not correctly handled
when the authentication mode was LDAP. It has been fixed and improved.

Text / binary filetypes recognition:

When a text based file "an example: makefile" was read-only, the detection was binary, this has been fixed.

cm help:

An error in the cm help label fixed: to apply a label recursively from the current directory the command is: "cm lb lb:LB001 . -R".

And many other bug fixes and improvements, review release notes for full details.

We hope you enjoy this release.

Codice Software team

Plastic SCM new forum - online!

2011-09-16T10:49:00.005+02:00

We are pleased to announce that we migrated our old forum which was based on "YAF - Yet Another Forum" to a much better one (IP.BOARD) from www.invisionpower.com .

The old link should be the same, since we redirect to the new forum, but just in case your link is still redirecting you to the old - non existent forum, try inserting http://www.plasticscm.net and update your bookmark.

Users + password have been migrated, but with the new system, generating "requesting" a new password is a 1 minute job, fully automated.

We hope you enjoy the new forum as we do, and feel free to share your ideas there with the Plastic SCM growing community.

regards,
miller

This is how I use the synch view

2011-08-15T13:07:00.004+02:00

Hi there,
How is it going with the 4.0 beta?
I’m going to start posting about what’s new in 4.0 and how you can use it to make things easier.
Today I’m going to talk about the “sync view”.

What’s the sync view all about?

The sync view is a very simple yet powerful functionality in 4.0 that enables you to connect two different repositories (which can “live” in different servers, separated by oceans, running on different OS, using different database backends… well, the usual) and check what’s need to be updated on each of them.

How does the sync view work?

Very simple: you define a “source repository” which is the one you “connect to” to drive the process. For instance, if you’re working in a distributed way, your “source server” will be your laptop and your “source repo” the repository you want to work with.
Then you define a “destination” repo as the place to synchronize with. Following with my disconnected scenario, your laptop will host your source repo and your company’s plastic server will host the “destination repo”.
Is it clear? Once you’ve selected the two, the sync view will connect to them and figure out what changes need to be pulled (from dst to src) or pushed (from src to dst).
Note: you know, if you just define the src repo and dst repo differently, the operation will have a different meaning.

Many scenarios supported

Well, as you read above the sync view is so simple and flexible that it is possible to support many different scenarios. We like to define them as follows:

Distributed developer: he will have his laptop or desktop as “source” and will typically have one “destination” server, the “master copy” (your office central server if you prefer). Optionally he could have more “destinations” to collaborate with other peers instead of restricting his pushing and pulling to a single server.

Multi-site environment: a company with two or more facilities, each of them running a plastic server. One of them will be the source and other the destination and sync will happen among them.

Distributed integrator: a network of distributed plastic servers (each of them running on each developer’s computer) and the sync view defined on the integrator’s machine as a way to be able to “pull” from all the contributors on a controlled way.

As you can see, the “sync view” is a rather simple tool although it can enable really powerful business scenarios.

Having a mirror server

This is my case: I have a “master server” at the office, currently running on a W2k8 machine named “Diana” and with a SQL Server backend.
I have other servers on my network and that’s why I have 3 different “sync configurations” as you can see below.

I have one to synch my laptop with “Diana”, a second one to synch “Diana” with an Oracle powered Plastic server, and the third one, the one I’ll be focusing on today, which syncs “Diana” with “Eunomia”, a Firebird embedded Plastic SCM server running on a tiny VM.
Once I click on “Diana-Eunomia” sync config I can see the following details:

It tells me there are “outgoing” csets from “Diana” to “Eunomia”, which basically means “Eunomia” will need some sync.
If I click to get the detailsl I see:

Which details the branches that will be synched during the process. Actually these branches are going to be “pushed” from “Diana” to “Eunomia”.
Finally I can click on a given branch and view which changesets need to be pushed:

The good thing (excellent IMO) is that now you can click on a cset and check the differences… even when it is remote (you’re not directly connected to that server at all!). It enables “replication preview” which we all missed with 3.0… didn’t we?

Wrapping up

There’s a real bunch of things on 4.0 but the sync view is really one of the important features, extremely simple, but really helpful and powerful. Enjoy.

Plastic SCM 4.0 Beta 1 is now out!!!

2011-08-09T16:52:00.007+02:00

Hi Plastikers! The time has come and we’re very proud to announce that our first beta of Plastic SCM 4.0 is out!

If you were already a subscriber you should be already enjoying the new version since we sent you a notification email a couple of days ago.

And the rest of you... well, please check what’s new here: we made for you by listening many developers like you and to read the evaluation guide we just developed to help you going through our first beta: http://www.plasticscm.com/releases/4.0-beta/PlasticSCM-4.0-evaluationguide.pdf

A lot more for you...
Clearly the big question mark is: what’s in there for me?: a lot, is the answer, but I’ll try to be specific and summarize:

For current Plastic SCM 3.0 users

We’ve been listening to your requests, your suggestions and wishes … and that’s a big part of what 4.0 is all about: a product that fit your needs!

Everything Much Faster	4.0 is much faster, switch to a new branch, label, merging… blazing fast as you wanted
Improved Branch Explorer	All the things you wanted to have including filtering, better improved searching, rearranging the diagram and some extras like subdiagrams
Better Replication Support	Much better replication support, including the sync view
Simplified Merge Operations	Core changes to simplify merge operations, branch creation and so on. Now changesets are kings and merge tracking and history is based on them
Transparent Change Tracking	Just change code and Plastic will take care of everything, even tracking what you’ve moved

For developers who never used Plastic before

You’re interested in the new paradigm: Distributed Version Control (DVCS), aren’t you? But probably you don’t feel like dealing with Git, Mercurial and other tools specifically designed for open source projects. You you need a system designed for enterprises or public institutions with the similar requirements . If that’s true, Plastic is for you.

Reduced learning curve

Reduce the learning curve because everything is visual and easy to use, which doesn’t mean it is not as powerful as it needs to be

One-click replication

Push, pull branches (full replication) with just a few clicks. Jump into the distributed age but with the simplicity and effectiveness you’re used to

Do use feature branching!

Step into the branching era creating feature branches in seconds, switching to them… merging back. You know, boosting your performance using the right tools, no magic, no “marketing buzz”, just the tools you need to help you work on your daily programming tasks

For managers

As a manager there are a few concerns you can’t remove from your mind: improving time to market, reducing development costs and increasing quality.

Well, Plastic SCM is not a silver bullet, so only your hard work and coordination with your team will make things happen, but you know having the right tools help. If all you have is a hammer, everything looks like a nail, doesn't it? Fortunately Plastic is not only a hammer.

How can Plastic help you?

Improve visibility

Visibility is one of my main concerns and one of the key points to improve since I first found it on Steve McConnel’s writings a decade or more ago.

Make sure you work in short iterations, you deliver fast and you work on a feature oriented way, getting deliverable pieces of integrations done. The usual “agile” way of thinking, isn’t it?

Ok, Plastic will help you implementing “branch per task”, the right tool to get “full parallel development” up and running. There are other patterns too, of course, and fortunately Plastic, all about branches, is the only one able to support them all

Enable collaboration between distant teams or “roaming developers”

Nowadays having team members sitting on different locations (whether it is at a different office or at home) is pretty common.

Plastic SCM is distributed, fully distributed, and it means it is the right tool for the job.

There are other tools out there, but Plastic is the only one designed for commercial use, for professional teams working on commercial projects

Learn more about what we have been working on

During the last months we’ve been writing a bunch of material to explain what we were doing with 4.0, I went through it and created a list below to help you go through the entire collection:

Several Facebook entries, sharing news about the development of 4.0 (screenshots and so on)

The making of Plastic SCM 4.0 at Flickr

Several entries at our twitter, including specific screenshots at TweetPic

Blog post entry "Distributed synchronization view... unveiled!"

Blog post entry "Pulling remote changes with DBrEx".

Blog post entry "unscientific 4.0 benchmark test"

Blog post entry "DAG rendering, take two"

Blog post entry "DAG rendering"

Video "Synch view explained"

Video "Synchronization view explained in detail"

Video "Xdiff again"

Video "Plastic SCM 4.0 feature branches"

Video "Plastic SCM 4.0 beta 1 installation"

Video "4.0 find renamed files"

Video "4.0 small changes"

Video "Plastic SCM 4.0 Distributed Branch Explorer preview"

Video "Transparent SCM preview"

Video "Distributed Branch Explorer preview"

Distributed synchronization view... unveiled!

2011-06-24T01:11:00.002+02:00

Here are the two screencasts I've just recorded showing one of the last features we've been working on during the last days: the distributed synch view.

You all know that Plastic SCM is a DVCS (Distributed Version Control System) and that we're trying to release the most complete possible DVCS toolset with 4.0. Well, the "synch view" is another step ahead: yes, you can ask the new Distributed Branch Explorer (DBrEx) to render remote branches and then pull from there, but we thought it would be really useful to have a "tree view" displaying the changesets (and branches) you need to push or pull between two different remote repositories... and that's how we started with the sync view.

It simplifies things so you see the branches you need to pull or push, the changesets on each of these branches, and you can even "diff" the csets to see what has been modified.

'Cause a picture is worth 1000 words... probably a video is worth 2000 :P, so here it goes, the long detailed explanation:

And a shorter one:

Remember you can already sign up for the beta version and also follow us on Twitter and Facebook.

Pulling remote changes with DBrEx

2011-05-25T17:06:00.003+02:00

The work on the upcoming 4.0 release continues, and as usual we try to keep you updated and also share how it is looking so far, so feel free to continue sending feedback, comments and so on. Remember you can see most of the 4.0 screenshots here, and some videos here (www.youtube.com/codicesoftware).
Since we’re already using 4.0 internally (remember, “eating our own dog’s food”), I wanted to share some of the new things that can be easily achieved with the new “branch explorer”, the “distributed branch explorer” or “DBrEx” as we name it internally.
I’m currently working on a task that is on my local repository on my laptop, and I’m about to start a new one and hence create a new branch for it (remember, the branch per task pattern). But, I’d like to start the task from the latest code on a certain branch, so I’d like to know if I have to “pull” some changes from the “master server” at the office.
My situation right now is the following: I have all the changes in branch /main/DAG up to the changeset after BL199, but I’d like to know if there are newer csets on the remote server. Also, please note that the colors of the changesets are different: the “green ones” are csets created on my server, the blue ones changesets that have been “replicated”, hence create remotely (this is already a new feature on 4.0)

In order to see “what’s new” on /main/DAG I’ll activate the “show remote changesets” option and grab data “for this branch only” from the main server. Plastic is “clever enough” to propose known repositories (repositories you’ve imported data from, in my case, only the main server so far). Activating it looks like the following:

Once the “remote data” is retrieved, the “DBrEx” will render not only “data from the local server” but also data grabbed from the remote one. Look at the following screenshot to see how “remote changesets” are rendered: we use “dashed lines” to highlight remote csets (csets that are not on your repo).

So, just a glance at the DBrEx and I know there are changes I’ve to “pull” from the remote server. In fact, I can do more than that, since I can right click on a remote changeset and “diff the changes”, which I think is a really neat feature (note to observers: yes, the options “merge from this changeset” and “create branch” shouldn’t be enabled on remote csets… that’s why this version is still internal, isn’t it???)
One really interesting note: compare the two previous screenshots: do you see branch br:/main/DAG/SCM9472?? Ok, when I didn’t have “remote data” I wasn’t able to find that the branch was already “integrated” remotely into the parent branch /main/DAG, but rendering the remote data for /main/DAG doesn’t only show me the new changes but also tells me that the branch /main/DAG/SCM9472 has already been integrated into /main/DAG… remotely. Cool, isn’t it?

Next thing is pulling the new changesets, and I’ll do the same I used to do in 3.0: just right click on the branch, go to replication and “pull this branch”. Easy.

And then my DBrEx will get updated once the remote changesets have been “pulled” from the remote server, as you can see below. Now the changesets are “local” (although coming from a remote source (that’s why they are blue)) and they’re not rendered with “dashes” anymore…

So, as you can see, 4.0 is all about DVCS, and the DBrEx is the next step to render distributed version control information graphically… or, at least, that’s our goal! :)

Setting up Plastic SCM with an external diff tool

2011-05-16T01:13:00.022+02:00

In this blogpost we will go through very few steps to setup an external diff tool to work with Plastic SCM. The tool we will use here is Beyond Compare from Scooter Software.

Motivation

Although Plastic SCM comes with a powerful diff tool, but there can be times were you want to use your preferred tool to diff some binary files of any type of your choice with your diff tool, an example here could be Microsoft excel files, which are not supported by our diff tool but Beyond Compare which is a dedicated file compare tool can handle.

The procedure described here to setup Plastic SCM with an external diff tool can be applied virtually to any other tool.

Lets start setting things up

Find your favorite compare/diff tool and install it; in my case I installed Beyond Compare to diff 2 excel files within Plastic Gui.

Beyond Compare executable is called BCompare.exe and can be executed from the command line with c:\BCompare.exe file1excel.xlsx file2excel.xlsx, so basically when you setup Plastic SCM with Beyond Compare and diffing from Plastic SCM on a revision of a versioned excel file, Plastic will call the BCompare.exe and feed it with the two filenames (or revisions) needed to perform the diff.

To setup Plastic SCM with Beyond Compare diff tool:

In PlasticSCM client go to-->Preferences-->Diff tools--ADD

In the Define Diff tool configuration window choose:
1. External Diff tool
2. Insert the full path to BCompare.exe with the needed arguments: "C:\Program Files\Beyond Compare\BCompare.exe" @sourcefile @destinationfile
3. Choose "Use this tool for files with extension:" .xlsx

Push "Apply & OK" to close the window.

Place the Beyond Compare for *.xlsx files to be the first in the list.

In PlasticSCM client items view, mark your excel sheet, do a "diff with
previous" or "diff" with any other revision.

Beyond Compare will fire on the two excel revisions that you diffed within
PlasticSCM.

Plastic SCM release 3.0.23

2011-05-06T17:59:00.016+02:00

In the latest releases of Plastic SCM versions 3.0.20 to 3.0.23 we introduced a bunch of new features and bug fixes. Beside the full release notes here, this blogpost will highlight some of them.
Just in case you haven't downloaded this version yet you can do that here

Let's start with new features:

ReviewBoard 1.6 support:

Plastic SCM now integrates with the latest ReviewBoard 1.6. ReviewBoard is a web-based Code Review tool from www.reviewboard.org and the current latest version of ReviewBoard is 1.6b1 and Plastic SCM is currently supported in this version and in the final release 1.6x

Review Board announcement: http://www.reviewboard.org/news/2011/02/24/review-board-16-beta-1-released/

And Release Notes: http://www.reviewboard.org/docs/releasenotes/dev/reviewboard/1.6-beta-1/

Bugzilla versions 3.6 and 4.0 support with Plastic SCM.

From Plastic SCM version 3.0.20 we support Bugzilla Bug tracking system from www.bugzilla.org

Eclipse: Added Annotate in the Eclipse Plugin

In Release 3.0.23 we added the support for Annotate in the Eclipse Plugin

Eclipse plugin: "Import from Plastic SCM" wizard redesigned

The "Import from Plastic SCM" wizard dialog has been redesigned, to allow expanding the repositories to show the existing branches on each repository, so that users can select directly the desired branch to import.

Eclipse plugin: New menu option

diff with LAST revision on branch when right clicking on an item. This operation is available also in the Sync view.

Eclipse plugin: When creating a new workspace (from the Share Project dialog) it is also possible to create a repository.

Bugs fixed - most important:

Plastic SCM server:

If the newest created repository was deleted and a new repository was created after restarting the server, the ID for the new repository was the ID of the last deleted repository and the operation failed. Now a new ID is generated and assigned to the new repository.

Visual Studio integration:

Fixed a bug related to open Plastic SCM views after adding a new solution to version control.

Eclipse plugin:

When the Eclipse workbench and the Plastic SCM were not in the same location and the project was multiproject, an update operation failed because Plastic SCM took the workbench root path as the workspace root path.

IntelliJ plugin:

The comments specified on the checkin operation were not reflected on Plastic SCM.

Team City plugin:

There was a problem when several Windows drives were configured to be used.

Improvements, visible and behind the scene!

Performance improvement on copy merge operation:

Although in the release notes this is mentioned as a bug, but in fact it is an improvement, In release 3.0.187.21 we improved the performance of copy merge operation when dealing with hundreds of files and directories.

The update report window improvements

The update report dialog may show very long messages and require scrolling to view them. Now, the full message is shown, and can be copied by right clicking on it and selecting "Copy error text".

Eclipse plugin:

Now branches and labels are loaded asynchronously; this way the Plastic SCM view is not blocked while the data is being loaded.

File types Recognition:

Text files are automatically detected and set as "text" type files by reading the first bytes of the file.

Last but not least view the full release notes for the complete list of improvements and bug fixes in the last 3 releases here, and we hope you enjoy the improvements!

Unscientific 4.0 benchmark test

2011-04-27T15:54:00.004+02:00

As you all know by now we’re heavily working on Plastic SCM 4.0, the upcoming release where we’re trying to put together all the suggestions we got from our user base during the last years (specially the “big ones” which can’t easily be included in minor releases) together with a number of “hard-core” changes impacting the branching and merging engine and the replication (distributed) one.

Hence 4.0 will come with a number of new features, including new GUI and new Distributed Branch Explorer but also heavily improving performance. And that’s exactly what I’ll be sharing today: how 4.0 performs in some simple ops against well-known DVCS.

I asked to gather some numbers after reading the following tweet from Eric Sink (the brain behind Veracity () and the great Vault).

So, we tried a similar scenario on a Dell XPS 13 Laptop (4GB RAM, 7000rpm HD… well, you can find the full specs online, not a beast!) running Windows 7, using two different sets: a small repo (similar to the one used in the previous tweet) and a “huge” one (similar to the ones used in the gaming industry).
And here you’ve the results: first the small one, add+commit 2752 files, 45MB: hg: 7.8s git 3.6 s plastic 3.4s

It is a really tiny test but we’re happy to outperform the other DVCS already.
We’re using: Plastic 4.0.192 (internal release) using SQLite backend, Hg 1.6.2, Git 1.7.4.msysgit.0.

And now let’s give a try to a biggest test using 192k files and 33k directories and a total of 5.82GB. I’m happy to announce that under these circumstances Plastic is even better (our goal is to become the best DVCS handling big files): 192k files, 5.82GB: hg: 1563 s git 1256 s plastic 601 s

Enjoy!

New documentation: migrating from other popular SCM systems

2011-04-27T15:51:00.000+02:00

Just a quick note to let you know that the main product documentation page on our Web site includes a new category, "Migrating from other SCMs". It contains writeups on migrating to Plastic SCM from these well-known systems: Microsoft Visual SourceSafe (VSS), CVS, Subversion, and Perforce.

These writeups are not "marketing fluff" -- they are technical discussions, aimed at helping users who are transitioning to Plastic SCM (or just thinking about such a transition!). We welcome all comments on these migration documents.

Merge: contiguous automatic conflicts produce a non automatic conflict?

2011-03-21T21:47:00.000+01:00

A few weeks ago, we received a support ticket showing a pretty specific merge case where our mergetool was prompting the user to resolve a non-automatic conflict. The changes on the source and destination revisions were on separate sets of lines, so at first sight they should be merged automatically. But the changes where contiguous. Let me show you the case:

The files I used are not related to the original question, but the case is the same. The user pointed that p4merge was not detecting conflicts and performing the merge automatically:

So p4merge is making your life a bit easier than Plastic's mergetool by doing some automatic operation for you, right? It's fine for a case like this. But let me show a similar example, this time with code.

Here is p4merge, with changes in separate lines of code on the source and destination and identifying both of them as separate changes. The merge is automatic:

However, looking at the result file, the code there is not likely the intention of neither of the developers. Now let's see how Plastic's mergetool does it:

In this case, mergetool is again detecting a non automatic conflict, but in this case, this is a better option, since the incorrect automatic result would otherwise remain unnoticed.
This is so because when dealing with code the context is important, and Plastic will check the context of the conflicts to determine if a situation can cause potential "merge pain". On that situation, the rule is "better ask than automatically resolve something potentially dangerous".

New writings available

2011-03-21T18:03:00.002+01:00

Check the latest "ALM Tools and Techniques" and there our writing about "Language aware SCM", unveiling some of the root ideas behind the tools we're development.

The first step was Xmerge & Xdiff, then "method history" but the best is still to be delivered :P

Plastic SCM release 3.0.19

2011-03-09T09:29:00.022+01:00

In this latest release of Plastic SCM version 3.0.19 we introduced a bunch of new features and bug fixes,
Beside the release notes here, this blog will higlight some of the things we introduced/fixed in this release.
Just in case you haven't downloaded this version yet you can do it here

Let's start with new features:

TEAM CITY CI:

Plastic SCM now integrates with Team City Continues Integration
from JetBrains through our own plug in get it here log in and download the Team City plug in

Mantis integration:

Now we support the latest Mantis 1.2.4

Shell Extension:

Include the annotate view. when right clicking on an item,
users will be able to annotate that item.

Visual Studio integration:

Added support for solution folders.

Check in dialog with task control now allows including recent comments:

When Plastic SCM is configured to work with a task control on task on
changeset mode, the check in dialog now allows including recent
comments, as the usual check in dialog.

Bugs fixed - most important:

Adding items from the GUI in Linux was not working:

This was a Mono issue related to return the focus to the parent window when the Comments
dialog was prompted.

The diff now opens as a separate window when it is called from the merge dialog or the 3D tree:

When diffing items from the merge dialog or the tree, the difftool was opened embedded as a
Plastic SCM view (when this setting was configured this way), which was not usable, since the
difftool was opened behind the dialog.

Branch Explorer:

When the last two changesets on a branch had exactly the same date, the
latest was drawn outside the branch.

Visual Studio integration:

There was a problem when the workspace that contains a solution binded to Plastic SCM was
deleted. Then, when the solution was opened in Visual Studio and the user executed a Refresh Status operation a null was reported.

Add dir + file was not recursive:

Selecting a file and a directory and performing an add operation from
the GUI did not add the directory recursively. Now the user can add recursively or non-recursively when a directory is selected.

Improvements, visible and behind the scene!

Active Directory authentication:

Although in the release notes this is mentioned as a bug, but in fact it is an improvement, Plastic
SCM was directing all the user queries to the central server instead of a remote (local) one if existed. This was causing performance problems since users needed to be resolved.
We where using an older method, now we use a new one GetDomainController method.
You will need to update the server to 3.0.19 to benefit from this improved AD resolution.

Shell Extension:

Performance issues noticed on the Windows Explorer related to external
drives (especially floppy drives) and network mapped drives when the Shell Extension was installed.

Improve search toolbar:

Search boxes in difftool, mergetool, code review and annotate view.
Now not only the buttons are clickable, but also the labels area.

Before

After

Improving some error messages:

The update report message "Can't load root item..." has been improved
to include more information about the causes of the error. In addition to this, if the user clicked on 'retry update' an assert false was
reported.

When diffing identical revisions a message with the caption "Error" was shown, now the caption is "Information".

last but not least view the full release notes for the complete list of improvements and bug fixes in this release here, and we hope you enjoy this one!

DAG rendering - take two

2011-03-08T23:07:00.009+01:00

A few days ago I posted about some DAG rendering techniques we’re using in the new Plastic SCM release we’re working on.

Today I’d like to go through the alternative rendering techniques, the pros and cons of each of them, and then try to grab some feedback about which one is better.

Motivation

One of the main consequences of the DVCS age is the huge number of branches repositories have to deal with. Previously SVN, CVS, VSS and others (and I’d include P4 and now TFS in this pack) avoided branching as hell. But now everyone is embracing branching, so a good way to draw an item’s history and parallel evolution is required.

I’ll describe how Mercurial diagrams work (inTortoise Hg 2.0), then will do the same for Git using GitK and GitHub network graphs.

Two rendering styles

There are basically two alternatives right now for displaying version control graph diagrams:

Vertical style: rendering nodes from top to bottom, top being the newest changes

Horizontal style: like the previous rotated 90 degrees clockwise

Mercurial style

Mercurial (Hg) graph rendering uses the vertical style. The graph focuses on “commits” (or changesets/checkins, if you prefer) which are drawn top-down, starting with the more recent ones and going back in time as you scroll down.
The basic elements are displayed in the following picture.

Commits are represented by circles, decorated differently depending on whether they’re simple, tagged, or loaded in the workspace. Each commit can have up to two parents. (In Hg every commit can only have one merge; multiple-merging is not supported.)

One interesting feature here is that branches are “bent” to reuse horizontal space when another branch ends. The graphic tries to be as narrow as possible, shrinking or growing horizontally depending on the number of parallel branches.

The next screenshot shows an actual image of a real repo, taken from the release notes of Tortoise Hg 2.0. I’ve highlighted a merge.

It is important to note that “merge links” are just lines between commits, with no special decoration. Of course, trained developers will immediately find them and recognize their meaning. “Branch terminators”, indicating that a Hg branch has been “closed”, appear as rectangles at the end of a branch.

Git(K) style

Let’s take a look at a GitK screenshot, maybe an overcomplicated one, extracted from http://blog.spearce.org/2007/07/difficult-gitk-graphs.html. Fortunately not all GitK graphcs are this hard to follow!

It’s clear that horizontal space can be wasted if there are too many active parallel development lines (branches) at a given point. I’ve marked a merge and, as with Hg, there are no special symbols to draw merges, just a line between two commits.

It is important to note that Git, unlike Mercurial, is able to handle multiple merges at the same time (a commit can have more than 2 parents).

GitK follows the same “vertical pattern” that Tortoise Hg uses. I find Hg rendering style more polished but I guess it is a matter of taste.

Rotate: enter the GitHub network graph

The GitHub “network graph” follows a more “traditional” rendering approach: branches extend from left to right instead of top to bottom.

It more closely resembles the kind of diagrams that most people draw on a blackboard when trying to explain how a project evolves.

You have to click on the commits to see the related information. This differs from the vertical style, where the comment, committer and date always appear on the right.

As time passes, the graph evolves to the right, with the dates represented like this:

Vertical style – pros & cons

Using a GitK screenshot taken on a Mac OS X machine (see http://effectif.com/git/making-gitk-look-good-on-mac), I’ll summarize the pros & cons of the vertical style. BTW, feel free to send comments/suggestions.

Pros

Scrolling down to move back in time is quite natural since we’re all used to it thanks to similar controls, such as list views. In fact, the entire graph is just a modified list view.

Branch lines are bent (Hg) or moved left (GitK) in order to reduce the graph width as much as possible. Following a branch over time is a simple “vertical trip”; you have to check if the branch moved left or right depending on changes made on other branches.

Cons

These days, most display screens are much wider than they are tall, so the vertical style does not make the best use of the available screen real estate.

When there are many open parallel branches, too many vertical lines make the graph hard to follow.

With GitK, the vertical space is even more constrained, since the graph usually occupies the top half of the overall window. (You can resize, but then you lose the bottom half of the window.)

Colorblind people might easily get lost, depending on the colors (this also applies to the horizontal style)

And some notes:

Merges are not drawn as different parent links, which could make the graph easier to understand. (We took care to do this in the Plastic SCM BranchExplorer.)

There is no specific representation of branches; branches are just rendered as lines between commits. (This is probably a controversial point for DVCS purists, since branches in Git and Hg, while extremely useful, are not as “strong” as they are in other SCM systems. (That is, the important concept is the “commit”, and the branch tends to be secondary. In fact, Hg is able to do “anonymous” branching.)

Horizontal style - pros & cons

The horizontal style is the one I’m more used to, because it’s the one we use (so far) in the Plastic SCM BranchExplorer. It also resembles quite naturally what we normally draw on a blackboard to depict releases, branching patterns on a project, and so on. The following picture shows a hand-made branching (or release) diagram. It seems more natural to draw it this way, because people are more used to graphs in which time is on the horizontal axis than on the vertical axis…

Pros

Better use of modern ”landscape”-style display screens.

More natural, since the graph better resembles blackboard diagrams of branching structures.

Cons

When there are tons of parallel lines (lots of open branches). you might have to scroll down to find your branch.

Conclusion, questions and thoughts

First some questions and thoughts:

None of the Git or Hg tools display “merge links” as such. Do you miss this information? (I ask this because I always draw it manually on the blackboard and we implemented it this way in our BranchExplorer).

I’m not aware of zooming capabilities on GitK or Tortoise Hg to deal with the branching diagram. Do you think it is useful?

Finding the perfect rendering technique seems to be difficult. For instance when repositories are big enough there will always be a ton of branches and commits (changesets), so rendering all of them can make the graphic confusing. One of the things we’re working on is having an option to render “relevant commits only” (only changesets that are involved in a merge or are at the beginning or end of a branch ):

Neither Hg nor Git displays “branches” as such, as elements. What do you think about it? I’m totally biased here towards what we do with the BranchExplorer but I’m more used to the following where branches are depicted as “first class citizens”:

In conclusion: drawing branch diagrams (or release diagrams, if you prefer) is not an easy task, because everything looks great when there are only a few branches and changesets involved, but easily becomes hell with real projects with tons of branching and merging.

Filtering – the ability to temporarily suppress the display of branches you’re not currently interested in – might be the best option to keep things under control .

DAG rendering

2011-03-03T00:39:00.006+01:00

If you don’t know what DAG means … lucky you! You’re probably a happy developer focusing on solving your own software problems, instead of delving into nitty-gritty version control details.

But if you’ve been in the coding community for the last 3 years or so, you’ve probably heard of “DAG oriented” distributed version control systems, such as Git. (I won’t include Mercurial here since it is, theoretically, a delta-based system according to the now famous "Getting Git" from Scott Chacon .)

DAG, which stands for “Directed Acyclic Graph”, is the underlying data structure that Git, and other SCMs, use to store the different versions you create.

While the DAG concept applies to the underlying structure, if you diagram the way changesets (“commits” in Git jargon) evolve, you’ll also get a beautiful tree that is… hey, acyclic too!

Painting trees

We’re working hard on the upcoming Plastic SCM 4.0 release, with a bunch of features under consideration -- from core changes to an even better merge to new visual tools, including a new BranchExplorer.

Today I’m going to share some of the concepts we’re using to render the evolution of the repository, the “changeset evolution” (or “commit evolution” if you prefer). This will help you understand the differences from Plastic SCM 3.0 and also illuminate the best way to render DAG-based version history.

It all started here

The diagrams below show some of our ideas for simplifying the display of version history, so that “what you draw on a blackboard to communicate with your colleagues” can become an interactive diagram, our BranchExplorer.

Since a good number of our new users have Git and Mercurial backgrounds, we thought that diagrams like these would make them feel more “at home”. Plastic SCM 4.0 will introduce some of these display strategies, which are similar to those of the most used DVCSs out there.

From paper to pixels – take 0

Here is one of the initial screenshots, similar to the conceptual diagrams above, but now implemented as an interactive graphic.

Zooming out, you can see a wider diagram in “DAG mode” (not a high-quality rendering, though):

Painting labels (or tags)

We’re also playing with some ideas to render labels in a more visible and interactive way than in Plastic SCM 3.0:

In Plastic SCM 4.0, labels will be fully clickable. Wewill also render them in such a way that you get some additional information even before clicking, such as when the same “changeset” has more than one label.

Going distributed

I don’t want to unveil all the details yet, so consider the next two as “spy photos” like the ones that show up on car magazines when a new model is still under development. (You know, you can get most of the details if you look carefully :P)

Right now I’ll just show some alternatives we’re working on with very preliminary screen shots. The following screen shot (which looks quite arcane to me now) includes some of the new labeled-changeset display along with information about different replication sources.

And finally, a much more polished screen shot quite evolved from the previous one (but we’re still not finished with BranchExplorer development!).

Wrapping up

In future posts, coming soon, long-term Plastikers will discover a bunch of forthcoming changes, while newcomers will still be able to see (and comment on!) some alternatives for diagramming repository evolution for a distributed version control system.
Stay tuned.

git interop

2011-02-25T22:14:00.002+01:00

Last December we launched “Git Jungle” a Git repository visualization tool for Git based on Plastic SCM code.

A few weeks later we released “Method history for Subversion” another step ahead in SCM interop (ok, this time just sharing some of our core features with other systems).

We’re working on the next big Plastic SCM release, 4.0, and one of the key goals will be SCM interop. We plan to have (we’re working on it) bi-directional synch with Git and SVN and then eventually add other systems.

We’re developing a Git fast-import and fast-export support which opens the doors to full import/export from Plastic to Git and hence conforms to the format that is growing as the “lingua franca” in the SCM world.

A little bit of jungle

Take a look at the git repository rendered by GitJungle.

And a sneak-preview of 4.0

And now the same repository after being fast-exported and fast-imported into Plastic (cm fast-import) and already showing some of the new (still unveiled :P) Branch Explorer features.

Enjoy and send us feedback!! :)

Upgrading Plastic SCM to Firebird Server

2011-01-11T23:55:00.004+01:00

When you install Plastic SCM on Window it will work with an embedded Firebird database. Firebird is very good in terms of performance for small teams, but sometimes you will need to upgrade to something faster, specially if you detect some operations are slow. Let's see how to do a very easy move: set up a Firebird server instead of an embedded one.

Motivation

If you see your update operation is too slow... then more often than not you're experiencing a slow backend. Sometimes it can also be due to the disk IO performance so do a quick test: go to your workspace and type:

cm update . --timer --stats --noparallel

And check the "SolveSelector" line. If it's bigger than, let's say, 3-5 seconds and your server is on the LAN... you've a perf issue!

Installing Firebird

At the time of writing this we just recommend to go for Firebird 2.1.3, so go to this page and download it: http://www.firebirdsql.org/index.php?op=files&id=engine_213. Installing it is just a matter of a few clicks.

Setting up Plastic to use a Firebird server

Really easy: stop the plastic service and then create a db.conf file on the server's directory location with the following contents:

(Remember: the entire "connection string" in a single line!!!!)


<DbConfig>
  <ProviderName>firebird</ProviderName>
  <ConnectionString>ServerType=0;User=SYSDBA;
      Password=masterkey;Database={0};Pooling=true;
      connection lifetime=60;Charset=UNICODE_FSS;
  </ConnectionString>
  <DatabasePath></DatabasePath>

</DbConfig>

Restart the Plastic server and you're done!

Method history for Subversion is here!

2011-01-03T22:51:00.006+01:00

Simply put: right click on a C# method in Visual Studio and find its history instead the entire file history: we called it method history for SVN!!

Yes, here it is: if you’re a Visual Studio programmer using Subversion (Eclipse developers will have to wait a few more weeks…) and C# you can start using our plugin right now: it provides a new context menu command:

This command launches a window that displays the most recent revisions of the file containing the method. Then you will be able to navigate the different revisions and be able to filter the ones that contain the method and the ones where the method has been modified. It doesn’t matter how heavily you refactored your code, the plugin will locate it!

How to get it

Download the plugin here. It installs in just a few seconds and then a new menu option will show up on your context menu on Visual Studio. Testing it can’t be easier.

Action

Watch it live here:

Motivation

95% of the time you check the history of a file you’re looking for the changes you’ve done to a given method, aren’t you? Then you have to diff the files and locate the method yourself. It becomes a real nightmare if the method has been moved around in the file or if it has been heavily refactored.

We developed “method history” as part of our Plastic SCM version control system. Now we’re sharing it with Subversion users to enhance their day to day operations and also introduce them to our technology.

Send us feedback!

“Method history for Subversion” is still in beta so we really appreciate feedback through our forum (http://www.plasticscm.net).

Right now it only works for C# code, but we will be adding Visual Basic and Java support soon.

What’s next??

“Method history for Subversion” is just in its first release and only available from Visual Studio. The next steps we’re considering are:

Add support for VB and Java and later C++.

Improve current C# support (it doesn’t work for properties yet).

Improving method search (being able to track renamed methods).

Eclipse plugin.

Git support!

Note for Plastic SCM users

If you’re a Plastic SCM user (you’re using the Visual Studio plugin) and want to give a try to the SVN methodhist… contact us first because the two plugins collide and can’t be used on the same Visual Studio session (you’ve to use one, then close, then use another one). For SVN users… it doesn’t collide with ankhsvn!! :)

Designing a better user experience

2010-12-28T19:54:00.005+01:00

A few days ago we were working on the new "method history" functionality and then we were making fun about the error message to pop-up when a user clicks in the middle of two methods (it doesn't find any method then) and tries to find the history of the "non-selected" method (well, we're the ones to blame here because probably a disabled menu would work better :P)

But, you know, sometimes you would like to come up with very, very strong error messages... wouldn't you? :)

So, considering today is the equivalent to April Fool's day down here... what about having some fun?? :)

Ok, and now the real video (remember it is already available in the latest Plastic version, yes, history of a method!!):

SSL Enabled Plastic Connections - Reborn!

2010-12-28T16:00:00.003+01:00

NOTE: This article is updated and maintained at this link here
Here are the instructions on how to configure Plastic SCM release 3.0.187.x
(x > 0) to communicate using a secure SSL channel between the client and server.
First download and unzip the following package. PlasticSCM_SSL_ConfigFiles.zip. Next we are going to copy these files to specific locations.

Server setup:

Stop the Plastic SCM server service from windows services

In Windows goto Start->Run->type "services.msc" and find the Plastic Server service and stop it.

Navigate to your Plastic SCM server installation folder and rename your current remoting.conf file to remoting.conf.bck.

From the zip file server folder extract the new remoting.conf to the Plastic server installation folder.

The provided remoting.conf file will configure your server to use the default TCP port 8084 for non-SSL client connections and TCP port 8085 for SSL connections.

You can change the Listening ports above by editing the remoting.conf file.

A plastic.key and a plastic.cert files should be generated for the SSL to work, these files should be placed in the Plastic SCM server folder.

to generate the files, we will use a certificate generator tool makecert.exe obtainable from the .NET SDK:

http://msdn.microsoft.com/en-us/library/bfsktky3%28VS.80%29.aspx

use the following command from within .NET SDK command Prompt: c:\>hostname

record the above hostname to use it in the following command to generate the certification files:

c:\> makecert -r -pe -eku 1.3.6.1.5.5.7.3.1 -n "CN=hostname" -sv c:\plastic.key c:\plastic.cert

see Figure 1

If a pop up window “create Private Key password” is shown, choose None as illustrated in Figure 2

Copy the generated plastic.cert and plastic.key from c:\ to the plastic scm server folder.

Edit the remoting.conf file for the plastic server to point to the above generated certificate files; find the section and update it as illustrated below.

<channel type="Codice.Channels.PlasticSecuredTcpChannel, 
 plastictcpchannel" port="8087" 
 sslCertificateFile="C:\Program files\PlasticSCM\server\plastic.cert" 
 sslPrivateKeyFile="C:\Program files\PlasticSCM\server\plastic.key"; 
 name="secured">

Start the Plastic server, and check the connections on the server machine to verify that server is listening on the right TCP ports, executing the following command from a command-prompt c:\>netstat –na –p TCP as illustrated on Figure 3

Client setup:

To enable the Plastic SCM client to connect to the Plastic SCM server using SSL, first extract from client folder within the zip file, the file remoting.conf that should be extracted and placed in the Plastic SCM client installation folder.
Complete the setup following the below steps:

re-run the Client configuration wizard, and point to the port that is used for SSL, in our case port 8085.

edit the client.conf file adding the following line:

<ServerProtocol>ssl</ServerProtocol>

see Figure 4

if you want to use the previous non SSL connection, you must remove the above added line in the client.conf file and re-run the Client configuration wizard, and point to the port that is used for non-SSL connections, in the default case port 8084.

The makecert.exe program is part of the Windows SDK, so Windows developers probably already have it. We found some easy instructions on doing this on another blog post here.

Setting up two Plastic SCM installations on the same machine

2010-12-24T05:39:00.013+01:00

A single machine can host multiple Plastic SCM installations -- that is, multiple instances of a repository server process, each with its own set of repositories. In this post, I'll address a specific case:

You have already installed Plastic SCM on a Windows machine. Now, you want to create a second Plastic SCM installation on that machine.

Here's the recipe:

To provide a home for the second repository server process, "clone" the server subdirectory within the Plastic SCM installation directory. For example, you can use Windows Explorer to Copy the server directory, then Paste it in the same location. Rename the new "clone" to server2.
You need to reconfigure the repository server process to listen on a different IP port (say, 8085). In the server2 directory, run the configureserver program to make this change.
You might need to reconfigure Plastic SCM's connection to its database back-end, so that the second installation uses a different set of database files. Still in the server2 directory, see whether file db.conf exists. If so, add a <DatabaseSuffix> subelement to this XML-format file. For example:
```
<DbConfig>   ...   <DatabaseSuffix>_s2</DatabaseSuffix>   ...</DbConfig>
```
If no db.conf file exists, the repository server is using the default database back-end, Firebird, which is embedded in the repository server and requires no configuration file.
You need to create a new Windows service for the second instance of the repository server process. Open a command prompt window in the server2 directory, and run this command:
```
plasticd --installservice --servicename=PlasticServer2
```
Alternative: use the Windows command-line tool sc ("service control"). Be sure to enter the entire command on a single line, and to leave a SPACE after each "=" character. For example:
```
sc create PlasticServer2
   binPath= "C:\Program Files\PlasticSCM"\server2\plasticd.exe
   DisplayName= "Plastic Server 2"
   start= auto
```
Start the second repository server process:
```
net start PlasticServer2
```
Use Plastic SCM client software to remove the "cloned" repositories from the second Plastic SCM installation. (This is necessary only if you're using Firebird embedded or SQLite and your databases are in the server's directory!!) For example, using the CLI's command for removing a repository:
```
cm rmrep myoldrepo@mymachine:8085
```

Plastic SCM Plug-in for Hudson CI

2010-12-23T20:00:00.005+01:00

In this blog post we will go through the very basic steps to setup Plastic SCM Plug in for Hudson CI and do some builds.

The Plastic SCM plug in developed for Hudson CI is basically an .hpi file which will be included in the HUDSON repository (working on it).

However, you can download the plug in from this link: Download_PlasticSCM_Plugin_for_Hudson
Just unzip the hpi file into .hudson/plugins, restart the server, and it should work.
For this Blog post my setup involves the following software:

OpenSuse 11.1_x86

Plastic SCM version 3.0.187.22

Hudson CI ver. 1.384 (also tried it with 1.398)

gcc-c++ ver. 4.3 (use it for compiling the Hello World sample with Hudson)

Test files you can download from this link: Download_Test_Files

Create a Plastic workspace and extract the test files into the directory of the workspace.
The test files are basically two files, a helloworld.cpp and a script file BuildHello that calls the g++ compiler and compiles helloworld.cpp. Add the files to Plastic SCM so they are controlled, as illustrated in figure1.

Figure 1

Now into Hudson:
Log into Hudson, in my setup: http://localhost:8080/

Navigate to Manage Hudson-->Manage plugins-->Installed (choose Installed Tab)
Illustrated in figure2

Figure 2

Plastic SCM Plug in should be in the list and enabled. (double checking here :-))
Plastic SCM plug in does not differ much from the other Hudson Plug ins, so let us create a project and do some builds.

New Job-->Job name: PlasticSCM_prj1-->Build a free-style software project-->OK

Illustrated on figure 3

Figure 3

Next page we will configure Source Code Managment-->Plastic SCM-->Selector (Insert Plastic SCM workspace selector, fig 4+5)
- Selector can be obtained by many ways, this is just one of them.
- CD to your workspace directory ex.cd \millerwks\prj1\
- execute cm showselector (cm ss) ex. \millerwks\prj1\cm ss
- Selector will be printed and could look like this example:


repository "default"
path "/"
br "/main"
co "/main"

On the same page under the Build-->Execute shell-->Command (Insert the name of the shell script BuildHello, fig 6)

Save

Illustrated in the next figures

Figure 4

Figure 5

Figure 6

And now we are ready to do a "manual build" without triggers, so go ahead and push the button Build Now as indicated in fig 7.

Figure 7

Well, after pushing the Build Now (for many times), I get Build failed which is not cool! lets try to find out what is causing the failing of this build.
In the Build History on the left I entered into the latest build, and clicked on Concole Output. see fig 8.

Figure 8

Ok, cannot find the build script Buildhello, checking figure 1 with figure 6, I inserted the name of the script wrongly, Buildhello instead of the correct BuildHello. So I go to the configuration of the project within Hudson and fix the name, as in fig 9.

Figure 9

A manual build now and things looks much better, fig 10 + 11

Figure 10

Figure 11

And it is by time we try if our hello program built correctly as illustrated in fig 12.

Figure 12

Announcing "method history"

2010-12-23T00:18:00.004+01:00

We’re very happy to announce our newest Plastic SCM release (3.0.13) including one of the features we’re most proud of: method-based history!

You can now select a method within Visual Studio, right click to show the context menu, and select “method history”. Plastic SCM will go through the file history and analyze the evolution of that specific method!!

Motivation

We have the impression that 95% of the time that you go through a file’s history, the reason is to check a specific method. That’s why we came up with this new feature. In fact “method history” is one of those things we’ve always wanted to implement, but of course we had to cover the SCM basics first. But, finally, it is here!

“Method history” is our first step into a “programming language aware SCM”, a path we will be walking during the next months. We have a bunch of ideas to combine the “method history” parsing technology with XDiff and XMerge, to come up with a new line of Plastic SCM functionality in 2011.

Action, please!

First, here’s a short explanation of what “method history” is about, with graphics:

Plastic will look for the method in every revision of the item. Right now the search has some limitations (remember this is beta software):

We only parse C# code (Java is ready but not deployed; VB and C++ will be next)

We don’t consider constructors yet (but we’re on it!)

We locate the method by name: next step will be finding renames too!.

A few screenshots to see it in action:

and

And finally a video (available in HD!):

How to try

Simple: download the new release and install the Visual Studio "package" (not SCC, the newest package) and simply give it a try.

What's next?

As I mentioned, a ton of new stuff:

Being able to invoke "methodhistory" from the "annotate" views in the GUI

Eclipse support

Multiple language support + improved C#

Tracking refactored (moved) code between files... (wow! yes, we're on it! :P)

Enjoy

Why merge tracking matters

2010-12-16T11:28:00.008+01:00

My goal with this blog post is to explain why merge tracking is so huge for all the Subversion, CVS and VSS users out there who still think “hey, I don’t care about the new SCM systems, I don’t need distributed development!”

I know the GitHubbers and Mercurial users and Plastikers out there know what I’m talking about, but for the sake of clarity: the new DVCS systems are not only good because they’re distributed, but specially because they’re able to handle merging correctly. (Yes, I hear SVN users shouting: “we do have merge tracking after 1.5”, I know, I know, and I still say… switch to another system! :P.)

So, I will try to explain why merge tracking is so important with a very simple scenario. Let’s go.

Change my code

I start with the following piece of code. We’re going to modify, in parallel, the fragment that is highlighted in blue.

Basically we’re going to do what the next image shows: one of the developers is going to make a change to the code on the “main” branch (“master” in Git jargon) branch and the other coder will modify it on “featurebranch” branch. You can visualize your Git repo history using GitJungle which displays graphics exactly like this.

Merging nightmare

Let’s go now and merge “featurebranch” back into “main”. This time we’re facing a “manual merge” because we’ve created a non-automatic conflict. It isn’t a very tough conflict to resolve, because only a small code fragment is involved. But in the real world, you sometimes have to deal with heavily modified files, and the merge isn’t so easy.

Almost every 3-way merge tool out there works in the way pictured below (whether you’re using KDiff 3, WinMerge, Araxis Merge, Guiffy or the great Scooter Software’s BeyondCompare!).

As you can see you’ll have to deal with the “base” (or common ancestor) and the two “contributors”. In our case: the file as it was at the beginning (base) and the two parallel changes made on different branches (destination, the revision made on “main” and source, the revision made on “featurebranch”).

Because we modified exactly the same code, the 3-way merge tool shows something like the following:

You, the developer or integrator, have to decide what goes into the result file. In this case the desired result is the following: we keep the new method introduced on “main” and the new loop variables introduced on “featurebranch”. And, the most important thing is: check the “merge arrow” that now is coming from “featurebranch” into “master”. It means the underlying SCM “knows” the branch is already merged. That’s the key.

And the fun starts when you merge again

What if know you need to make a new change on the same file on the “featurebranch”? Suppose the “merge” wasn’t so trivial and it took you quite a few minutes to figure out how to resolve it. I bet you wouldn’t like to go through it again, would you?

Well, the magic of “merge tracking” is that it will allow you to make a new change on “featurebranch”, on the same file, and merge it again but without having to merge again the conflicts you already resolved! That’s the key and that’s something you didn’t have with older systems (and probably the main reason why you used to hate branching and merging before…).

The following image shows how you’ve introduced a new change on the branch, and then it will be time to merge again.

Common ancestors – finding the root of all revisions

So, what will happen now when you try to merge from “featurebranch” back into “master”? Well, thanks to the “merge link” the system created before, some things will change.

Look at the situation before doing our first merge. The contributors and the ancestor are highlighted. As you can see, the changeset (commit) tagged as BL189 is the common ancestor.

But now, when you’re going to merge again, the common-ancestor calculation will be different.

Now the newly calculated “common ancestor” for the merge is the recent changeset on the “featurebranch” (the contributor to the first merge). And the results of the first merge, including all the difficult-to-resolve conflicts, are recorded in the “main” branch contributor. With all the complicated work behind it, the merge algorithm can deal only with the new changes on “featurebranch”, and merge automatically for you.

Wrapping up

So, well, that’s all: I’m sure you’ve faced a situation like the above. Only having full merge tracking will save the day!

New manual: Introduction to Plastic SCM

2010-12-15T19:16:00.001+01:00

I'm happy to announce that a new manual, Introduction to Plastic SCM, has joined the product documentation set. It's available as a PDF, at http://www.plasticscm.com/releases/3.0.1/plastic_intro.pdf . This new "Intro" goes wide, but not deep. It's intended to give you a feel for what you can do with Plastic SCM, and for how (and how easily) you can accomplish SCM tasks with this great product!

For the most part, this manual replaces the Plastic SCM User's Guide (which also was called the "Introduction" in some places). But there is some reference-level material, such as the details of the configuration language for the workspace's selector, that is not included in the new manual. So don't get rid of your "User's Guide" bookmark just yet!

We love to get feedback on all our work, so please don't hesitate to send questions, complaints, and compliments to doc@codicesoftware.com.

A plugable Plastic SCM server

2010-12-11T16:04:00.008+01:00

Yesterday I got a SheevaPlug development kit and the first idea that came to my mind was “hey, let’s put a Plastic server here!” I’m involved in a small robotics project at the university (I’m an associate professor in Computer Science, although robotics is not my area) and we’re evaluating different alternatives to use as the robot brain. But yes, before moving some engines I wanted to check if it was possible to set it up as a Plastic server.

The look and feel

Well, I just took a few pictures of the “pluggable computer” today, close to my BlackBerry so you can see how small it is.

Start up

First thing is to go and plug the “thing”. Then it is supposed to start up and get an IP address from your router. That’s what I did, then went to my router configuration and checked that a new box was online!

Then I followed the instructions here to connect using ssh and log in. Cool!

Setting up

Follow the instructions step by step, all of them, including the one related to the time and date settings because otherwise you’ll end up in trouble when installing packages. It takes just a few seconds to go through all the commands. (I didn’t set the date at the beginning and jumped into mono installation and… ouch! Didn’t work!)

Installing mono

Again, really simple and well documented here. It’s an old 2.0 Mono (so I will try to come up with a newer 2.8 in the coming days, but just stayed with this one for the initial tests).

$ apt-get install mono-2.0-devel

And then don’t forget to install the following one too (otherwise you won’t have remoting and Plastic won’t work!)

$ apt-get install libmono-system-runtime2.0-cil

Copying Plastic

I just copied the Plastic SCM server binaries into /root/plastic/server and then run:

$ mono plasticd.exe –console

But… it didn’t work!

First thing I hit was that the SQLite libraries installed by default on the box were not ok to work with the Mono wrapper.

Ok, first things first. Here’s my db.conf to use a SQLite backend:


<DbConfig>
  <ProviderName>sqlite</ProviderName>
  <ConnectionString>Data Source={0};Pooling=true</ConnectionString>
</DbConfig>

Installing SQLite

First I got the package and then installed gcc and make

$ apt-get install wget
$ apt-get install gcc
$ apt-get install make
$ wget http://67.18.92.124/sqlite-autoconf-3070400.tar.gz

Then I built the sources with the following flags:

$ CFLAGS=-DSQLITE_ENABLE_COLUMN_METADATA=1 ./configure && make

Then I just added the .libs path inside the SQLite src dir to the LD_LIBRARY_PATH (hey! I know it is not clean but I’m just doing a quick test!)

Starting up Plastic

I typed:

$ LD_LIBRARY_PATH=/root/sqlite/sqlite-autoconf-3070400/.libs:/usr/lib:/root/plastic/server: mono plasticd.exe --console

And it … started up!

But then I connected from another machine and got a beautiful zlib related error. Why? Because Plastic wasn’t correctly loading zlib, so I did the following “fix” (from the server’s path):

$ ln -s /usr/lib/libz.so.1 libz.so

And then I restarted and everything worked!

Ideas

Well, I really love the idea of the “pluggable Plastic SCM server”. I’m using this one as a “spare mirror server” where I automatically push my changes from my laptop on checkin. The “plug” doesn’t have a lot of “disk space” (flash) but an external card can be plugged in or even an external hard drive. Or, even better, I’ll give it a try connecting the Plastic SCM server on it to an external MySQL database… Cool, isn’t it? I mean, for $99 you can have a really cheap mirror server (unless you’re a team with 100 developers or more but, hey!, then don’t be so cheap and buy a real backup!! :P)

Welcome to the jungle!

2010-12-10T14:13:00.006+01:00

Note to readers: I strongly recommend reading this post while listening this.

And now... for those about to Git… we salute you! We’ve just released GitJungle, a small, beautiful Git repository browser using our Plastic SCM Branch Explorer (BrEx) visualization technology that basically lets you look at your Git repo from… well, a different angle.

How to download it

Simply go to our just released labs page, read a little bit more about it and then download the binaries (remember you will need Mono installed if you’re a Linux or Mac OS X user).

How to use it

I feel I don’t have to explain you how to clone a git repo but for the sake of completeness here are the instructions to view a repo from GitJungle:

$ git clone https://github.com/jquery/jquery.git
$ cd jquery.git
$ gitjungle .

And you get the beautiful graphics!!

Action not words!

Watch it here:

Warning - experiment zone ahead!

We've just released the GitJungle beta! It's an experiment, it looks cool, it's usable, but it's not free of issues. If you find any… tell us!

We've also used the same core technology behind the Plastic Branch Explorer, which shows history in a horizontal way instead of the vertical way GitK and other UIs use. Suggestions, hard critics and applauses are welcome!

Why are we releasing a Git tool?

We develop and sell Plastic SCM, the most powerful commercial DVCS to date, the one with the best visualizations, multiple database backends, integrated ACL security, superior branching and merging support… ok, let's cut the marketing speech!!

Yes, we do focus on Plastic. However, developing GitJungle only took us a few days so, why not share it?

But, answering the question - we're working on the next version of Plastic SCM and our goal is to make it more interoperable than ever, and two-way synchronization with Git will be one of the key features there.

Also, Plastic SCM is a DVCS for companies and Git is totally focused on OSS projects, so why not collaborate? Git is teaching branching and merging concepts. Also, it’s educating the entire world about distributed development. This is fantastic for Plastic since we can expand and elaborate on these same concepts and practices while at the same time release a tool for software development companies based on these concepts (note: no, Plastic is not based on Git, we had a lot of hard work developing our own core, our own database layer, merge algorithms, security and all the funny things!).

Plastic Themes

2010-12-09T23:34:00.006+01:00

Today I'll come up with a small tip and no, it won't be related to branching, merging, replicas or patterns from the Linux kernel... promised!

An easy one for a Thursday, cool?

Ok, I'd love to have something as cool as the Chrome Theme Gallery but let's start small: do you know your current Plastic SCM GUI client is able to change the top banner so you can customize it and look cooler than any of your colleagues?

Look, suppose you want to give your GUI a more Christmas-time style:

Cool, isn't it?

Ok, in order to change your banner:

Create a beautiful png image (500x56 aprox)

Save it as banner.png at your Plastic client location

Restart the Plastic GUI and... you're done!

In case you want to give a try to the Christmas banner, just download this one:

And now a quick look at my own private banner gallery... ;)

Well, I know you're all very busy "pros" doing important stuff with Plastic but... maybe you can give it a try, or even better, design and share your own!! :)

Enjoy!

DVCS for everyone

2010-12-07T22:46:00.009+01:00

Or, an illustrated guide to DVCS...

As you’ve probably realized, I’ve started writing a series of blog posts, trying to be as “educational” as possible, and covering topics that range from the history of SCM to branching patterns to the way in which the folks working on the Linux kernel make the best use of branching patterns.

My challenge for today is to try to turn the distributed development tiger into a friendly cat, unable to scare anyone. I know a good fraction of the readers are not really scared of DVCS at all (you Git, Hg, Plastic and Bazaar coders out there!) but since we released our free version one month ago I receive more and more emails from people saying things like “hey, yes, I need better branching and merging but… what’s all this noise about being distributed?”.

So here goes, I’ll try to give you a very easy explanation.

Version control scenarios

The main scenario you’ve been using while getting your hands dirty with Subversion, CVS, Perforce, Team Foundation Server or any of the beautiful version control systems out there is something like the following:

One server handling version control and a bunch of coders “checking in” to it. Easy and comfortable, isn't it?

Then you’ve heard of “distributed development” at places like github.com or at any of the open source projects that have migrated away from Subversion to Git during the last two years (like Ruby or Mono, just to mention a couple).

If you’re a hard core OSS guy, you probably don’t have doubts about what it looks like, but if you’re working in a different environment (maybe small companies, corporations with tight rules and so on) maybe it is not so clear. The first idea that comes to my mind is something like the following:

The big change is that instead of having a central server, now everyone is “running his own version control system” (whether it is a real server or just a .git directory sitting on your working copy is not really important at this stage) and exchanging commits (checkins) in a peer-to-peer way. If you want to, you can unplug from the network, leaving all those internet connection and speed issues behind. (Yes, I know is 2010 but we developers hate waiting and speed is never enough for us, is it?)
But, for the more “centralized-all-under-control” of you out there… I bet this will look like a total mess! I hear you crying “what are you talking about? No central location? Are you crazy?”.

Well, give me a second. Pure DVCS is about … well, about being totally distributed. But reality is a little bit different, so behind the DVCS buzz we all end up having a “central copy” somewhere (or a “master copy” if you prefer). Kernel developers rely on Linus having the “real thing” and the rest of open source projects… well, rely on github.com or something similar, as the following figure shows:

So… don’t panic! There will be a master copy of your beloved source code!

Developers can continue exchanging modifications in a peer-to-peer way, but at the end of the day they’ll be pushing their changes to the central location.

In fact, if you think about it, the different “servers” around won’t be exact copies of each other (not required at least) but the important stuff will be safely stored on the master and replicated among the “developers” for greater safety. (An experimental branch will be only on your computer, or maybe shared by one of your colleagues. But the changes for 3.0 release will be shared by everyone and stored on the master server.)

Networking is key

If you look at the centralized vs distributed scenarios, you’ll clearly see there’s a big difference in terms of the networks where they operate. Centralized is great on LANs, speed is high, latency is low and…well, everything is great with a gigabit-per-second cable plugged to your laptop, isn’t it?

Distributed development grew up because developers always need to work faster than the available network supports. Face it, working against a local repository on your machine is faster than accessing an office server, whether it’s LAN-based or Internet-based.

(There are a bunch of other reasons, too, basically related to branching and merging as I always try to explain, but, ok, speed plays its role.)

Don’t let them fool you...

You know what marketers do best… yes, try to fool all of us ;). I hope none of my marketing friends is listening but, you know, nowadays “distributed development” is a big word and everyone is trying to hop aboard the “distributed ship”.

Let me explain: there are a few truly distributed version control systems out there: Git, Mercurial, Bazaar, Darcs from the Open Source world (yes, I know I’m missing your favorite one, I always do... ); and BitKeeper and Plastic SCM in the commercial dimension. (My beloved Plastic can work in centralized mode too… hey, yes, we’re flexible.). Period.

But, “distributed” is cool, so a guy from the marketing department at company X stands up and says “we’re distributed too” without even changing a line of code of their ancient system. And I find myself having to explain why my system is distributed and the other is not… crazy!

Well, a picture is worth a thousand words:

If you take a centralized system and make it listen on a TCP port for clients connecting over the Internet… it is still a centralized system! Period. Ok, I feel better now.

Multi-site development

Well, some of you are probably thinking now “God! I just wanted to link some offices together, what is this guy talking about?”.

And if you’re thinking that… you’ve probably heard about “multi-site”, haven’t you? Remember the extremely expensive ClearCase Multi-Site functionality? Wasn’t it great? Well, I’ve to admit I’d like to be able to charge as much as Rational did for it but, you know, we’re not in the 90s anymore. What good-old CC was able to do for a fortune is now available, for free or at a moderate cost.

If you’ve got several teams working on different sites, then you’re most likely used to the following picture:

Just to clarify: the “cloud” is “The Internet” not a super-cool cloud computing thing.

Well, here are the challenges: while developers at “Site A” enjoy the full speed of their LAN connection to their central server, the developers at “Site B” are jealous because they must access the server using slower connections, theyhave to wait… (and to make things even more dramatic, I drew the diagram using single-monitor desks for the folks at Site B… :D).

Unless the two sites are connected by some sort of super-cool-fast connection, this setup will end up causing problems. It happened in the past, it happens today and it will happen tomorrow. And connections, nowadays, never seem to be fast or reliable enough. (ok, now I’m waiting for the comment from some guy at “mega-corp”, saying they have a trillion-bps connection that only costs half a million a year and everything just works. Thanks. Yes, we know you’re sooo rich.)

The good news is that the same “technology” used to create distributed teams over the Internet (DVCS) is available to connect your distant offices and moving the “Site B” developers to the “premier league”.

Each site will have its own “central server” and then communication between sites will only happen when the “central servers” replicate changes back and forth. It can be done on demand, it can be done once a day, or it can be done continuously. The point is that “it can be done”.

Distributed is for you… yes it is!

If you’re still thinking distributed “is not for me”, let me try once more. Suppose you’re working on your centralized team with a centralized server but one day you feel like working from home (or going at the customer’s site to fix this really urgent bug -- you know, the kind of things real coders do). Then you’ll be like the guy in the following picture:

What’s the problem here? Well, you’ll be facing the same “slow-downs” that the folks at “Site B” had. Can you live with it? Ok, fine, but, wouldn’t it be better to use something better?

(Please note I gave you a joystick so you can have some fun while waiting for the SCM to finish pushing bits through the Internet :P).

Even on a centralized team it would be great to have the freedom to go offline sometimes, wouldn’t it? And that’s basically what the next picture is all about:

You’ll end up checking in locally, being able to create branches, check differences, walk the history and so on. And you’ll push changes back to the central server only when you feel like doing it… (maybe while you try the latest GT5 after a long day of work… ok, just kidding!).

Short guide through DVCS essentials

I won’t try to come up with a full description about distributed version control operations because I’ve already done that in the past (check http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html and http://codicesoftware.blogspot.com/2008/07/distributed-software-development.html). But I think is a good idea to wrap up with a quick explanation of the main operations, so that newcomers to distributed feel it is not hard at all.

While the main “version control” operations are “checkin” and then probably “branch and merge”, the main distributed operations are: clone, pull and push. And they’re depicted in the following diagram:

Basically, you start with an empty repository and then clone it from somewhere else.

Then you’d like to get the new changes someone put on the central server, wouldn’t you? You’ll use a “pull” for that.

And finally you’d like to make your changes available on the central server, too (or some peer’s copy). You’ll use “push” for that.

I definitely skipped the funny part here: what happens if two developers made concurrent changes in two “replicas”? For now just consider they’ll be able to fix them before doing a “push” because the system will detect it and ask you to merge the changes. This should be enough until you fully jump into the gory details...

Enjoy.

Plastic SCM Plug-In for Zutubi Pulse CI 2.0.x

2010-12-07T14:50:00.064+01:00

This article is written as a guide to setup Plastic SCM version 3.0 with Pulse 2.0.x (x= 48 - 51)
This article is updated and maintained at this link here
We will go step by step through the process to setup Pulse, Plastic SCM and nant.exe to successfully make continues builds.

Installing

Install Zutubi Pulse 2.0.x.

Install NAnt 1.90.

Setup nant.exe to be in the PATH environment.

Install Plastic SCM 3.0

While installing Plastic SCM, remember to choose to install Zutubi' Pulse Plug-In as illustrated in Figure 1.

Figure 1: Plastic SCM zutubi Pulse Plug-in

Choose the Data folder of Pulse as illustrated in Figure 2

Default folder would be: c:\Documents and Settings\user\.pulse2\data

Figure 2: Pulse Data path

After successfully installing the above programs, start Plastic Client and create a workspace.

We will use the default repository that is created with the installer.

Setup the system

Plastic SCM

Copy the Plastic SCM client cionfiguration file client.conf

From:

In Windows XP:

C:\Documents and Settings\<LoggedInUser>\Local Settings\Application Data\plastic

In Windows VISTA / 7:

C:\Users\<LoggedInuser>\AppData\Local\plastic

To:

C:\ProgramFiles\PlasticSCM\client

Pulse

Start Pulse2 log-in and Add new Project. See Figure 3

Figure 3: Pulse add new project

Add new child template as illustrated in Figure 4

Figure 4: Pulse add new child project

Name the project as desired, and push next. See Figure 5

In select SCM Type page, select Plastic SCM, and push next. See Figure 6

Figure 5: Pulse project name

Figure 6: pulse choose Plastic SCM

Insert the Plastic SCM workspace selector into the Pulse template workspace selector box as illustrated in Figure 7.

You can view the selector from the Plastic SCM Client GUI, or from the command line cmd.exe window by executing the following command from within the local
workspace folder: c:\workspaceprj01>cm showselector

Check the configuration from within Pulse, and push next button as illustrated in Figure 7

Figure 7: Pulse workspace selector and check

Select Project Type executable project from the drop down options list and push next. see Figure 8

Figure 8. Pulse project type executable

In the executable field insert nant

Figure 9: Pulse define executable, nant

Figure 10: Successful builds with Pulse and nant through Plastic

Integrating Plastic SCM with Trac Issue Tracking

2010-12-03T17:44:00.009+01:00

Hello, Plastic SCM user community! My name is John Posner, and I'm happy to introduce myself as a new member, having joined the Codice team as a technical writer. Actually, the technical writer. I arrive with some pretty good SCM credentials, having spent most of the past two decades in this field. I was on the original team that developed Rational ClearCase, and was also the first tech writer at AccuRev. (AccuRev claimed to be "ClearCase done better" -- with some justification, IMHO. An AccuRev stream managed to serve as both a branch and a label – pretty cool, but hard for many people to understand and use.)

I've spent the past couple of weeks learning Plastic SCM, and now I'd like to share some of what I've learned. Codice makes a big deal of "task-based development" and a "branch per task" approach, so that's one of the areas I focused on. Since Codice doesn't have its own issue-tracking system (ITS), this approach can work only if Plastic SCM plays well with existing, popular ITSs. And since this sort of thing is pretty complex, I was hoping to find some juicy bugs -- one of a tech writer's greatest joys!

I took a look at Codice's list of ITS integrations, currently eight of them, and decided that Trac was in my comfort zone. This open-source ITS is built in Python, which I've used a lot over the past decade. (The Codice guys seem to be into Ruby for scripting, but I forgive them.) So I fired up my Windows 7 laptop, an HP Pavilion dv7, and jumped in.

Download Party!

Here's a list of the software I downloaded, all of it free:

Plastic SCM (www.codicesoftware.com) – the new Community Edition is free, forever, for up to 15 users.
Python 2.6.x (www.python.org)
Python module distutils (pypi.python.org/pypi/setuptools) -- this module includes a very useful executable, easy_install.exe.
Trac 0.12 (trac.edgewall.org/wiki/TracInstall)
Python script that supports usage of Trac's "digest authentication" username-password scheme
(trac.edgewall.org/wiki/TracStandalone)
XML-RPC plugin for Trac
(trac-hacks.org/wiki/XmlRpcPlugin)
Subversion (I used an installer at http://sourceforge.net/projects/win32svn/files)

Whoa – what's Subversion doing on that list? It turns out that the XML-RPC plugin code is stored in a Subversion repository -- go figure!

In this age of Windows wizards, software installation is pretty straightforward, so here's just a brief outline of how I proceeded:

I installed Plastic SCM in the standard way, into the standard location C:\Program Files\PlasticSCM.
I installed Python in the standard way, into the standard location C:\Python26.
(OK, I confess: both Plastic SCM and Python were already installed on this machine when I started this little exercise.)
I installed Python's distutils 0.6 module using the wizard in setuptools-0.6c11.win32-py2.6.exe. This places easy_install.exe in folder C:\Python26\Scripts.
At a command prompt, I used this command to install Trac:
easy_install Trac==0.12

As with distutils programs, Trac programs get placed in folder C:\Python26\Scripts.

In a Web browser, I went to trac.edgewall.org/wiki/TracStandalone and copied this script for creating username-password entries, storing it as file trac_digest.py:

from optparse import OptionParser
# The md5 module is deprecated in Python 2.5
try:
    from hashlib import md5
except ImportError:
    from md5 import md5
realm = 'trac'

# build the options
usage = "usage: %prog [options]"
parser = OptionParser(usage=usage)
parser.add_option("-u", "--username",action="store",
    dest="username", type = "string",
    help="the username for whom to generate a password")
parser.add_option("-p", "--password",action="store",
    dest="password", type = "string",
    help="the password to use")
parser.add_option("-r", "--realm",action="store",
    dest="realm", type = "string",
    help="the realm in which to create the digest")
(options, args) = parser.parse_args()

# check options
if (options.username is None) or (options.password is None):
    parser.error("You must supply both the username and password")
if (options.realm is not None):
    realm = options.realm

# Generate the string to enter into the htdigest file
kd = lambda x: md5(':'.join(x)).hexdigest()
print ':'.join((options.username, realm,
                kd([options.username, realm, options.password])))

It was a bit too soon to install the Trac XML-RPC plugin at this point, so I didn't. A little massaging of the Trac environment is required first.

Setting Up the SCM and ITS

With both the SCM and ITS systems installed, I set up some data to be used by their integration. Chances are you're like me: more familiar with Plastic SCM than with Trac. So I'll gloss over the Plastic SCM details and spend more time on the Trac details.

To set up a Plastic SCM environment for the integration, I performed the following operations in Plastic SCM's beautiful, capable, speedy GUI: create a new repository; create a new workspace; create a few text files in the workspace; in the Items view, place the files under source control:

... and in the Labels view, create label BL_01 and attach it to everything in sight:

I just had to illustrate those last two commands; they're right there when you need them, sitting at the top of their context menus. Sweet! (Another confession: to create files in the workspace, you need to go outside the Plastic SCM GUI.)

Next, I set up a Trac issue-tracking environment in folder c:\nov9trac:

Go to the Python scripts folder, where the Trac executables were installed, and initialize a new environment:
> cd C:\Python26\Scripts
> trac-admin C:\nov9trac initenv
Create a digest entry for user jjp (that's me), using the script I download in Step #5 above, and store it as a one-line text file
> python trac_digest.py –-username=jjp –-password=any > auth_digest.txt
Give myself permission to do just about anything in this Trac environment
> trac-admin C:\nov9trac permission add jjp TRAC_ADMIN
Start a Trac Web server for this environment, listening on port 8765 and using the one-entry digest as its username-password database. The command prompt window becomes the Trac Web server's console
> tracd -–port=8765 --auth=nov9trac,auth_digest.txt,trac C:\nov9trac

With the Web server up and running, I fired up a Web browser and connected to the server. I made sure to enter a URL that included the exact hostname/portnumber combo that appeared in the Web server's startup console message:

A Trac intro page appeared, where I logged in as jjp (the only Trac user so far):

Then, I created some Trac issue records, called "tickets".

For Ticket #1, I chose the title Alpha Project; for ticket #2, Beta Project, and so on. (Inspired choices, huh?)

Setting Up the Integration

Just about all the work I had done so far was to set up the Plastic SCM and Trac environments separately. Now for the fun part: getting the systems to work together. The integration is based on a tried-and-true (that is, old) network communication technology: XML-RPC. Here's the basic idea:

When a particular branch is selected in the BranchExplorer, Plastic SCM makes a remote procedure call (RPC) to the Trac server. The server returns field values from the Trac ticket that is associated with the branch.

Each Plastic SCM branch is associated with a Trac ticket, and each Trac ticket represents an engineering task. Et voila (or the Spanish equivalent), "branch per task" is a reality.

Setting up the integration was just as straightforward – configuring the Trac server to use XML-RPC, and establishing a protocol in Plastic SCM for associating branches with tickets/tasks. Here's how I enabled XML-RPC support in Trac:

I downloaded and installed Trac's XML-RPC plugin (which involved performing a Subversion checkout):
> cd C:\Python26\Scripts
> easy_install -Z -U http://trac-hacks.org/svn/xmlrpcplugin/trunk
I enabled the XML-RPC plugin by adding these lines to the end of the Trac environment's configuration file, C:\nov9trac\conf\trac.ini:
[components]
tracrpc.* = enabled
XML-RPC calls are to be made by an unauthenticated Trac user, named anonymous. So I created this user and give him (her? it?) permission to make the calls:
> python trac_digest.py -–username=anonymous –-password=X >> auth_digest.txt
> trac-admin C:\nov9trac permission add anonymous XML_RPC

And here's how I turned on the Trac integration in Plastic SCM:

In the GUI, I selected Issue Tracking in the top-level toolbar:
In the Issue Tracking dialog, I (1) selected Trac as the issue tracking system; (2) specified a branch prefix, establishing the protocol that all Plastic SCM branches with names of the form tktNNN are to be linked with Trac ticket NNN; and (3) specified the URL of the Trac server – the same URL I used when creating the Trac tickets.

To make sure that I'd done my work correctly, I (4) clicked the Test Connection button (and held my breath). It worked the very first time – no kidding!

Using the Integration

Finally, it was time to test the integration between the Plastic SCM and Trac issue tracking systems! Using the BranchExplorer, I created a subbranch of /main, naming it tkt0011. (Would those leading zeros cause a problem?) I refreshed the BranchExplorer display, and sure enough – the new subbranch was annotated with the title of Trac ticket #11: Kappa Project.

So far, so good!

Next, I clicked Show Extended Information in the BranchExplorer's toolbar, and then clicked Edgewall Trac Extension in the extended info panel. Uh-oh, the panel was blank. Then I figured out that the BranchExplorer is not telepathic – I was thinking about the /main/tkt0011 branch, but I hadn't selected that branch. Clicking on the branch revealed a very nice extended information display:

And to get access to the actual Ticket #11, I double-clicked in the extended information panel:

That's the integration – simple to set up and simple to use!

I know what you're thinking: did I find any bugs in this facility? Sure I did! If Trac's Web server is not running, trying to launch the BranchExplorer causes the Plastic SCM GUI to hang. I also thought of an enhancement: when looking at a ticket, the Trac user should be able to see what files have been created/changed for that task. It should be easy to implement, since it's just the set of revisions created on a particular Plastic SCM branch. That's one of the beauties of a branch-per-task approach. I'll try to get the Codice guys to address both these items. Bye for now!

DVCS explained - working disconnected

2010-12-02T17:53:00.005+01:00

I recorded a short screencast/presentation explaining what distributed version control is about, focusing on disconnected development. Distributed development is much more than that, but let's start with a simple scenario that is very helpful for teams all sizes.

I just focus on how a DVCS helps you working disconnected and allows you to share (push) your changes back to the main server.

Hope it helps!

Linus on branching...

2010-11-29T22:55:00.003+01:00

A few months ago, Linus Torvalds shared some interesting thoughts and concerns regarding the Git branching patterns being used in Kernel development.

Since learning what Torvalds has to say is always enlightening, I wanted to delve into the points he mentioned, because they align pretty closely with the techniques we recommend with Plastic SCM. Obviously, the points apply to Git, Plastic SCM, and any other SCM with good branching support, too.

Linus’ words

This is what Linus wrote (I only extracted a fragment, for the complete text, go to http://lkml.org/lkml/2010/9/28/362).

The real problem is that maintainers often pick random - and not at all stable - points for their development to begin with. They just pick some random "this is where Linus -git tree is today", and do their development on top of that. THAT is the problem - they are unaware that there's some nasty bug in that version.

Shooting a moving target

What is Linus talking about? Actually, it’s one of the very well-known issues with trunk development that I described here in the section titled “don’t shoot moving targets!”.

This problem hits “mainline/trunk pattern” followers hard, since they keep updating to “what’s more recent”, probably due to fear of merging. Continuous integration delays the problem, but doesn’t solve it. But this problem can also hit those following a “feature branch” pattern, unless they follow all the rules.

The problem they’re facing is shown in the following picture:

The kernel team uses branches, but what if they’re using the “master” as an integration branch and they’re branching off commits that are not tagged? (As the picture shows).

The problem is that the master branch can be used as an integration point and hence get commits that leave the branch in an intermediate, unstable state. (This is especially true when using fast forward merges on Git, which I don’t really like precisely due to this issue. But I guess Linus must be doing real merges because he DOES know how to use Git. :P) Then you branch from an unstable commit and… you end up in trouble!

Baselines are key

We had exactly the same issue with some teams using Plastic because they failed to understand the importance of baselines. Once your code is stable, tag it, label it, and create branches ONLY from this well-known point!
That’s basically the rule of thumb: create baselines frequently (as many as you can) which of course must be fully tested. (That’s the time-consuming part, since integration is pretty fast nowadays with modern SCMs) and then CREATE BRANCHES ONLY FROM STABLE BASELINES, as the figure shows:

This way if something fails on your task branch (feature branch) you know… it’s your fault!!, because all tests were fine on the baseline -- not just the fast integration ones (like the ones you can run on checkin with continuous integration tools) but also the slow ones that you use to validate a release.
Very easy rule of thumb, great savings!

Moved code detection

2010-11-24T22:21:00.002+01:00

Since we launched the Community Edition we've seen a huge increase in the number of downloads and also the number of teams jumping to Plastic all around the globe.

While Plastic has always been free for education and open source, our main intention with CE is to reach small teams and help them in their transition to DVCS and parallel development. Most of the software companies out there have less than 15 users and they're exactly the ones we're targeting with CE.

That being said, I wonder if all the new people using Plastic is aware of some of the really cool features we've implemented in 3.0. Do you know Plastic can detect moved code both in the diff tool and the merge tool??

Check the following posts:

Moved (and modified) code detection on diff

Moved (and modified) code detection during merge

And, you know... tell your colleagues!!! :P

Live to merge, merge to live...

2010-11-23T18:09:00.013+01:00

This blog post was initially published back in 2008 at DDJ but since DDJ "Guru blogs" moved to the new location some images have been broken so I've decided to publish it again here.

Live to merge, merge to live...

As a professional programmer you’re familiar with a variety of programming languages, you know by heart the basics and the not so basics of data structures and algorithms. You are an expert working in your favorite IDE. You master software patterns and you’re aware of the newest trends in agile methods. But there’s a useful tool in the programmer’s toolbox which is normally more feared than used: the merge tool! This article will explain, step by step, the very basics of merging and will explore the different merge types, their uses and advantages.

Fear of merging

So, you write code, don’t you? And there’s a big chance that you don’t develop code in isolation, right? The code you write for your projects is normally scattered across a number of files. And, according to the Pareto Principle, 20% of the files in your project will receive 80% of the changes. You can try to trace a bad design smell here, you can try to refactor your code from top to bottom day and night, but, unfortunately, that’s just reality: if you and your team work on a project, there’s a huge chance you’ll end up editing the same files at the same time.

For a number of projects out there this is a big problem. I’ve found a number of project managers and software designers trying to avoid concurrent modification wrestling their project plans and software designs. Wouldn't it be better if they were putting such efforts into making better software and finishing it on time?

But, there’s an ancestral fear behind this behavior: the arcane fear of merging. “Hey, if you and me modify the same file... we’ll have to reconcile all our changes!!”. And of course, they assume it will be a painful and error prone process. “So, let's schedule our changes so that only one of us touches the file at the same time”. Ouch!

Long ago software development was about lone eagles working alone. Now software development is about new languages, new tools, but at the end of the day it’s all about collaboration. And, avoiding collaboration doesn’t look like the smartest way of getting the best out of a team.
Then, why are we initially so scared of merging our file changes? I find two key reasons:

Lack of knowledge about how merge tools really work. People tend to think about code merging as some sort of magic process able to understand their code in order to combine changes. They don’t believe code can be always correctly understood by the system, and they don’t trust merge tools. Of course, under their assumptions, they’re right. The problem is merge tools don’t analyze or understand the code, they just apply some simple and clever rules to combine texts. The same way you trust your compiler will generate the right machine code, you should trust your merge tool.

Past bad experiences: merge tools and their big brothers the version control tools, have evolved during the last two decades. You’ve probably experienced some awkward issue with an old-fashioned (but still alive) version control system. Believing they’re still the same, is like still preferring coding in assembler because you don’t trust compilers.

Merging explained: automated conflicts

Do you know how a merge tool works? Let’s take a look at a very simple example. I won’t dive into the obscure algorithm details but just make a 1000ft flyby.

Suppose we have a piece of code like the one at the next figure. Then you and I start making changes on the file at the same time. I make a couple of changes at the beginning of the file, and you add a new method below.

Merging our changes manually is possible; it is a small file so it will just take a few minutes to do. It will require both of us to carefully look at our changes, but we’ll make it.

Of course the picture changes if we’ve changed not one but 15 files in total, and up to 8 have been modified in parallel. Also, what would happen if, instead of only the two of us, 5 other people were working on the code at the same time? Yes, the process is doable, but it is time consuming, error prone and... boring!! I bet you have better things to do than manually combine files.

But, what would a merge tool be able to do in our previous example?

The tool will find an automatic conflict. Look carefully, our changes don’t collide, so what we would do manually would be just copy and paste my changes on the right part of your file or vice versa. It is very simple, but doing manually is error prone. This is exactly what a merge tool will do: just put the two set of changes together, with no possible collision or conflict.

Normally, during a merge, the tool won’t even bother asking you to look into such a conflict; it is so simple it can solve it by itself. Of course, almost all the tools out in the market will allow you to set a mode in which all conflicts are reviewed by the user. It will just propose the changes, but you will be the one actually making the decision. Do you feel safer now? Ok, I bet after a week of manually reviewing trivial conflicts you’ll switch to automated mode.

The next figure shows the results of the first merge and how a merge tool will combine the changes together to create the result (remember to click on the images to make them bigger).

You’re in trouble: manual conflicts

But, a developer’s life can be exciting and full of challenges, but it is not easy. So, eventually you’ll face a situation like the one depicted by the next figure:

Yes, know we’ve modified exactly the same code in one of our changes on the file, which makes things much more complicated.

Now you can say “the tool can’t know the right solution!”.

And you’re right. But, as I told you, the merge tool is not a wizard’s device; it is just a programmer’s tool. So, use it correctly and it will make your life much easier.

The 4th figure shows a merge tool in action letting you decide what to do with your manual merge conflict.

Under these circumstances the tool will always prompt the user. It will still save you precious time because it directly focuses you on the problem, but you’ll have to make the decision yourself.

So, the merge tool will help you with automated conflicts not even asking you if you don’t want to (and honestly, it’s the right choice) and will ask you for help whenever it finds a manual conflict, which is basically a code fragment with changes made by two developers at the same time.

The rule of thumb is very easy and will help you trust the tool because there’s no complex code analysis behind it. It just looks into the lines of code: if only one contributor changed the fragment, it is an automatic conflict, otherwise, it is not trivial and the tool will ask.

2-way and 3-way merging

What’s all this fuss about 2-way and 3-way merge tools? What are they all about? Ok, that’s what I’ll be explaining in the next few paragraphs. It basically depends on the number of file versions you consider for your merge operations.

So far, what you’ve seen is a 3-way merge in action:

You have the original file: it is the file as it was at the beginning before a specific set of changes were performed by our developers.

Then you have the file you have modified (remember the previous examples).

And finally the file I’ve modified.

The result file is the one created after the changes are combined, the one at the bottom of the previous Figure (some tools prefer to hide the base file and just show the result one).

I didn’t explain 2-way merge yet, but it’s not very complicated: it doesn’t consider the base file (also known as the common ancestor) for the merge.

Is it better? Simply put: no, it isn’t. 3-way merge knows what you’ve added or removed to a file while 2-way merge can’t because it doesn’t know how the file was at the beginning.

But, still, I’ve found developers who seem to be more used to 2-way merge tools. Let’s try to figure out why.

Let’s go back to the original Java file, make a couple of very simple changes, and try to merge them with a two-way merge tool. Check the results on the next image.

Do you see the problem? Basically, at each difference the 2-way merge tool won’t be able to decide whether it is modified or removed code, so it will always have to ask you!

This may be good for the paranoid but, believe me, if you have to manage a good number of merges, you’ll end up wasting your time.

The same two conflicts would be automatically solved by a 3-way merge tool.

Of course, there’s a remark here: you can only use 3-way merge with a version control tool handling your code. Otherwise you won’t have access to the base file unless you have a very good memory or a crazy naming convention to keep your old files...

Merge tracking, what’s in it for me?

If you’ve never heard of merge tracking... well, welcome to a whole new world. You’ve probably heard about it after Subversion 1.5 had been released. It has finally introduced merge tracking. It still has some caveats but it’s evolving in the right direction. Many other systems out there have had merge tracking since long ago and most had it as part of the core product since their inceptions.
Anyway, what does it mean?

Merge tracking is deeply related to version control tools. You can run a file merge in isolation, but with merge tracking you rapidly enter the field of SCM (whether you want to translate it as Software Configuration Management or Source Code Management is just your choice).

Merge tracking is also deeply related to branching, but I’ll try to postpone the topic as much as possible.

Have a look at the next image. It represents the merge we’ve been running in the previous examples. We have the original file and then your changes and mine drawn as some sort of tree or graph.

After I merge your changes with mine, a merge link is created telling the system I’ve merged your changes with mine. Also, I would like to highlight that during this change we modified exactly the same lines of code, so it will be a manual merge... Remember it because I’ll use it below.

What’s the benefit? First: you know what you’ve done since your version control system takes care of this information. If you don’t have it, it’ll be harder to figure out what happened.

But, let’s make another set of changes with our sample files. You can check how our tree looks like after the changes at the next figure.

You make a new modification and I make another one, and once the two of us are finished, I decide to merge your changes back with mine again.

How does merge tracking help here? First of all, you remember I mentioned above our first merge was not automatic, don’t you? So, what’s the benefit of merge tracking? It will just merge the changes after the last merge happened, and you won’t have to solve the same manual conflict again. It greatly simplifies merging because it will let you focus on what’s new and you won’t have to merge all the old stuff.

How does the merge tool know what to merge? In any three way merge you’ll need a base (or original file) and two contributors. In the sample highlighted at the previous figure the version control tool, with the help of merge tracking, will first try to find what’s the base file for the two changes we have (two revisions after all).

And how does the system locate it? It will use your tree of versions and try to locate the closest parent revisions of the ones you’re trying to merge. The algorithm is known as nearest common ancestor and it is about finding the closest parent of a couple of nodes on a directed graph.

In our sample the next figure shows the base or common ancestor for the two revisions we’re trying to merge.

Look carefully, if the merge link wasn’t there, the parent would be the original revision, and then the merge tool would have to ask you again about the previously solved conflict (the code would be the same at the two revisions but different from the base).

The merge arrow solves the problem allowing the underlying system to correctly identify which one is the new base for the merge.

Branching

I don’t know whether you realized or not but... we’ve been using branching!

Look back at Figure 7 (two figures back). There’s a set of changes named your set of changes and a set of changes named my set of changes, right?

Well, they’re actually two different branches which is nothing more than a couple of sets of revisions.

They allow you to have parallel sets of changes, which is great when you’re doing development.

It can’t be easier.

I feel like a myth buster today, but as you can see, branching, one of the concerns for a number of developers, is not an issue at all.

Unfortunately branch management is a nightmare with some old fashioned version control tools (think about CVS or SourceSafe, for instance, and even SVN until merge tracking becomes mainstream and stable), and that’s the reason behind all this fear...

Wrapping up...

So far we’ve introduced all the basics (and not so basics) of merging. As you have noticed it is not a difficult task at all once you correctly understand the steps and contributors involved.

Merging is one of the daily tools of a professional developer, but still unknown for a wide amount of users. Mastering the process will make them more productive and will allow projects to evolve faster.

Fixing a bug – the branch-per-task way

2010-11-19T16:37:00.014+01:00

This is based upon a real story: I have a piece of code that launches an external application, but it wasn’t taking into account the possibility of having programs with spaces in their pathnames. Something like “c:\mypath\tool.exe” worked, but not something like “c:\program files\my tool\tool.exe”. To be able to launch such programs, we need to enclose the pathnames in quotes.

The code

The original code was something like the following and obviously unable to deal with quotes.

Issue tracking system

First things first: we need to start with a task in an issue tracking system. Internally at Codice we use TTS (task tracking system), our web-based app for issues. (Yes, if you’re interested in it, I can tell you we’ll be releasing it soon.) The task I’ll be working on is 8651.

Creating a branch for the task

Nothing fancy here: just go to the BranchExplorer and create a new branch for the new task. The branch will be based at a well-known point, the latest known stable release.

Next, I’ll switch my workspace to the new branch and start editing the code.

Initial refactoring of the code

First, I’m going to modify the code to extract the argument parsing to a new class named ArgsParser. I modify the original code as follows, to create an ArgsParser object and then use its members Program and Args.

Just after I write this code, I checkin the changes, explaining it was a first step in my refactoring. REMEMBER: Because I’m using a task branch, I’m free to create as many checkins as I need, without affecting the other developers!

Inspect the first change

Look at the BranchExplorer after the first checkin:

Now I inspect the changes contained in the changeset on branch SCM8651. (It’s the second one you see in the picture. The first cset in a child branch is just there to keep track of its connection to the parent branch).

And then I launch the Diff changeset content view, which contains two panes: the top pane shows all the files modified in a cset; the bottom pane shows the line-by-line differences for the currently selected file.

It is a nice interface, isn’t it?

We detect moved code!

But, wait, let’s take a deeper look at this diff. Do you notice the two buttons close to the difference and the line going down? The next figure shows these details.

Scrolling down following the line, we get to the ArgsParser class implementation I talked about before:

Plastic is able to track the moved code! It has figured out that the original lines of code have been moved to a method in the new ArgsParser class. Amazing, isn’t it??
Even better is the second button over the difference. It runs a sub-diff. I click on it.

The sub-diff shows how I’ve modified the code AFTER moving it to the new location, renamed the variable names, introduced some class members and so on. Plastic is still able to track it!!

Completing the change

After my initial refactoring, the next step is to actually add the code that handles the quoted program pathnames.
I’ll make this change and also add some unit tests to check that my code is fine.
Once I’m done I can go to the Pending changes view in the Plastic GUI (or invoke View Changes in the Visual Studio plugin):

and checkin three files.
Now I look at how the BranchExplorer renders the current situation, with a new changeset being created containing the second change.

Inspecting the changes

One of the really cool features in Plastic is the ability to “walk changesets” inside branches, one by one. If you’re careful doing your checkins (as I have been here) your branches will tell a story, a very complete one, describing every change in detail and greatly helping reviewers. (Sometimes just seeing all the differences in one step is not as useful as walking the changes one by one, nor so easy to understand.)

Here’s the view created by the Explore changesets in branch command:

This view is very much like the one I used above, Diff changeset content, but with an extra dimension. Instead of exploring the contents of a single changeset, I can now explore all the changesets of my branch.
As you can see, walking the changes one by one is very, very easy this way.

For distributed developers – push your changes back

Once I’m done, I’ll run my test suite and then go to our issue tracking system and set the task as finished.
Since I’m working with a local Plastic SCM server on my laptop (remember Plastic is a DVCS), the last step is pushing my branch back to the main server. I can use the BranchExplorer for this, too, using the Push this branch command.

Wrapping up

Now it is your turn to ask questions! Do you see the beauty of branch per task (or task oriented, if you prefer) development, using Plastic SCM’s powerful visual tools?

The version control timeline

2010-11-15T12:38:00.004+01:00

Software Configuration Management (or source code management, for you real hard core coders) has been around for quite a few years, slowly moving from an almost manual-labor, dark prehistory to the shiny days of the DVCS (distributed version control system).

You’ve all used at least one of the SCMs on the following list, but are you aware of how long the system you’re using has been around? Do you know the big names? Ok, that’s what I’ll try to supply with this short compilation.

The big picture

Look at the following diagram to find some of the main names in SCM history. Yes, I must be missing a good number of them, so don’t be shy: post a comment and I’ll update the list with your favorite one I missed :)

If you’re still feeling good about using really “old irons”, I’ve added some pictures of how “cell phones” looked like when the SCMs were released, so you feel older and bloody outdated :). So yes, if you’re using CVS and still think it’s ok, look at the cell phone directly below “CVS” in the diagram. Do you feel like Gordon Gecko (Michael Douglas) in “Wall Street, Money Never Sleeps”, getting his brick-sized cell phone back as he leaves jail?

Prehistory

There was a time when you stored your versions manually. Ok, for many of you this time wasn’t the 80s, but a few years back when you were at college naming your source-code archives exercise.zip, exercise-0.zip, exercise-good.zip, exercise-good-final.zip, and so on. Well, believe it or not, there was a time without real SCMs. It was always dark and people were living in caves.

RCS

Then 1982 came and RCS was released. RCS is not a huge piece of technology, but you can still find it around in Unix distros. It is simple and straight to the point.

One nice feature was that text changes were stored as deltas (pretty important, considering hard drives used to be small!). Deltas are still used nowadays by most SCMs.

Some RCS drawbacks worth mentioning:

It is text only.

There is no central repository; each version-controlled file has its own repo, in the form of an RCS file, stored near the file itself. For example, the RCS file for /usr/project/foo.c is /usr/project/foo.c,v -- or a little better, in a subdirectory, /usr/project/RCS/foo.c,v.

Developers make private workspaces by creating symbolic links to RCS subdirectories – say, a symlink from /usr/home/john/RCS to /usr/project/RCS.

Naming of versions and branches is downright hostile. A version might be named 1.3, and a branch might be named 1.3.1, and a version on the branch might be named 1.3.1.7.

The classic era

In the SCM arena, the 90s are the classic era.

CVS

It all started with CVS (Concurrent Version System) in 1990. It was able to handle multiple versions being developed concurrently on different machines and stored on a central server. The client-server age was upon us and developers took major advantage out of it.

CVS was able to handle versions in a decent way. And it even supported branching and merging, though it wasn’t very good at doing it. That’s one of the reasons many people are scared about the “B” word and the “M” word.

CVS didn’t track directories or filename changes (no refactoring allowed here!) and heavily relied on locking the whole repository. It is outdated now, but it worked in the 90s! (If you have it, just walk away and go on to something else!)

PVCS

Polytron Version Control System (PVCS) was initially released in 1985 and then went through a series of mergers and acquisitions: Polytron, then Sage, Merant, and finally Serena.

It’s an old, outdated system (initially designed to avoid branching/merging, using file-locking instead), but it’s still supported by Serena Software.

ClearCase

In 1992, one of the major beasts in the SCM world was born. ClearCase was clearly ahead of its time and for some it is still the most powerful SCM ever built.
Outdated, slow moving, over priced, and overly complicated to administer (in the early days, you had to generate a new Unix kernel to run the beast!), good-old CC isn’t the cool guy anymore -- you can hardly find anything positive about it on the net. But it’s still very good at branching and merging and still has unique features, such as its legendary “dynamic views”. While powerful, CC came from a time when disk space was scarce and networks were mostly LANs, with no concerns for things like latency or working through firewalls.

Atria (the developer of ClearCase) merged with Pure (which was run by Reed Hastings, now the head of Netflix), was purchased by Rational and then IBM. And lo, the powerful CC stopped evolving. Well, it did evolve towards UCM in the early 2000s, which basically got rid of all the good things and left the weak ones, together with a huge price. Not very good idea.

ClearCase is still one of the most-used SCMs in the corporate world, and certainly one of the revenue leaders.

VSS

All the systems on my list had their moment and their clear advantages over previous systems. All except Visual SourceSafe. VSS was a weak system from day one, forcing developers to work with a “locking” approach, discouraging parallel development and creating a huge “fear of merging”.

Slow, error prone, and utterly limited, VSS has been one of the most-used systems by Windows developers around the world. It is still in use, spreading pain and fear among good-hearted coders. But VSS was ahead of its time in one sense: it more properly belongs in the “dark SCM middle ages” (see below), instead of the classic era.

VSS was entirely graphical, which was probably one of the reasons why it was widely adopted (along with being closely tied in with Visual Studio distributions).

Perforce

Perforce (P4) is one of the independent vendors who are totally focused on SCM, battling for the SCM gold. It is still one of the market leaders among mid-range companies with huge teams, and it has a strong presence in some market niches, such as the gaming industry.

When it was released in the mid 90s, P4 was one of the most affordable and powerful systems to date. Worlds ahead of VSS and CVS, it was never at the level of Clearcase. But it was able to clearly beat CC in cost, performance, and ease of use.

Being centralized and not very good with branching and merging (branches are implemented as subdirectory trees – didn’t they ever hear of metadata?) P4 doesn’t seem to be the best option for the future, but it is rock solid, mature, and well established. That will help it keep growing. At the time of this writing, P4 is the biggest code repository inside Google. Cool!

Enter the middle ages

A time of darkness, when most of the previous advances were lost and a degraded environment emerged…

Subversion

Subversion (SVN) was conceived as “enhanced CVS” and its developers hit their target: it is better than CVS. Period.

Although systems like ClearCase were perfectly capable of branching and merging, SVN educated an entire developer generation on the following dogma: fear branching and merging at all cost! This caused environmental damage that persists to this day, only starting to be healed by the new DVCS generation.

SVN was close to P4 in features, and spread like crazy: more than 5 million developers around the world use SVN on a daily basis. Huge!

SVN is extremely simple to use and evangelized everyone on the “mainline development model”. Error-prone (break the build!) on non-toy projects, it helped developed techniques like “continuous integration” as a way to “avoid integrations”. While the idea is good, most of the surrounding concepts were clearly limited by the tool itself.

Linus himself raged against SVN when he first introduced Git back in 2006.
During 2009 and 2010, all major open-source projects on earth gravitated away from SVN. A good sign of how wrong SVN was. But it’s still big and won’t die for ages.

AccuRev

Born in an age of darkness, AccuRev was developed as an entirely new approach to source control. Its original way of doing things still seems new to lots of developers nowadays.

AccuRev has strong support for branching (“streams” in its jargon) and merging. It has played a valuable role in helping the community move away from ClearCase and older tools like CVS.

Enter The Renaissance

After an age of darkness, an entirely new generation of SCM systems broke the established status quo. “SCM is a mature market” was the analysts’ conventional wisdom, but the new generation broke onto the scene and blew everything apart.

Able to sever ties with the Internet and work unplugged (like cool rock stars), the new generation also excels at branching and merging, which was touted as the root of all evil during the “dark ages”. These new systems have successfully shifted the tide in the “branching/merging is good” direction.

BitKeeper

BitKeeper was one of the innovators in the DVCS field. Designed by Larry McVoy (who previously worked on TeamWare, Sun’s internal version control system, built on top of SCCS, long evolution story here…) it rose to fame in 2002 when the Linux kernel development team started using it. A huge flame war started, with some developers complaining about using commercial tools for the world’s premier open-source project.

Things only got worse in 2005 when fights with the core kernel developers grew even bigger. BitMover, the company behind the product, became concerned about people reverse-engineering their code. They discontinued support for open-source development and, ironically, thus prompted the creation of Git to fill the gap.
For more, see http://en.wikipedia.org/wiki/Bitkeeper.

Git

Linus Torvalds, the father of Linux himself, designed and implemented the first version of Git (almost over a weekend, in pure-hacker style) to give his kernel developers an alternative to BitKeeper. Linus not only did the original design (simple, clean, genius), but helped promote the project with his unique style. (See http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html.)

During his famous speech, he heavily criticized (ok, insulted) CVS, SVN, and Perforce: “Subversion has been the most pointless project ever started”, “If you like using CVS, you should be in some kind of mental institution or somewhere else” and finally “Get rid of Perforce, it is sad, but it is so, so true”.

You can love him or hate him, but he definitely made his point: the Middle Ages were over and now distributed systems were to rule the world, including removing the arcane fear of branching and merging, a key concept behind every DVCS.

During the next years, every major open-source project migrated away from Subversion towards Git (and www.github.com provided a really huge, huge hosting service), making it the strongest and coolest SCM on earth.

Git is based on a DAG structure (Directed Acyclic Graph), in which the main unit of change is the changeset. It implements full merge-tracking, but at the commit level instead of the individual file revision level (as, for instance, ClearCase does). It is extremely fast, with the only caveats being management of large binary files and the requirement to replicate repositories in their entirety.

Git is clearly influenced by its kernel roots, and it’s obviously not the easiest thing on earth to use . But it will definitely be the SCM of the next decade. Check out this awesome book.

Mercurial

Mercurial (Hg) was first announced on April 2005, also rushing in after the BitMover decision to remove support for the free version. Hg is also one of the key open-source DVCSs, along with Git. They can even work together quite well: Scott Chacon, the Git evangelist and one of the best SCM tech writers ever, wrote a nice integration -- see http://mercurial.selenic.com/wiki/HgGit.

But Hg differs quite a bit from Git in terms of design. They share the concept of commit/changeset as the unit of change. Git implements this based on trees; each tree points to an older tree, and so on – hence the DAG. With Hg, every changeset is a flat list of files and directories, called a revlog.

(For more on Hg, including internals, see http://mercurial.selenic.com/wiki/Design and http://mercurial.selenic.com/wiki/DeveloperInfo.)

Mercurial provides very strong merging, but it’s a bit different from other SCMs in its branching model: it has “named branches” but the preference is to create a new repository as a separate branch instead of hosting “many heads” inside a single one.

Joel Spolsky has written an extremely good Hg tutorial (hginit.com), which will help a lot of new users. Spolsky’s company, Fog Creek Software, has recently released Kiln, a commercial wrapper around the Hg core.

Darcs

Darcs (Darcs Advanced Revision Control System) is another open source attempt to get rid of CVS and Subversion. It started in 2002 and has been continuously evolving since then, reaching version 2.5 in November 2010.

The major shortcomings of Darcs have been performance and its different way of handling history: instead of managing “snapshots” (commits or changesets) it manages patches, but in a way that makes traversing history difficult to understand. (a current status may have not been a real snapshot).

Bazaar

Bazaar (bzr) is another open-source DVCS, which tries to provide some fresh air to the SCM world. While less used than Git and Mercurial, Bazaar features interesting features, such as the ability to work in a centralized way, if needed. (The “pure” DVCSs didn’t include central servers in their original design.)

Bazaar was developed by Canonical (yes, the Ubuntu company!) and became GNU in early 2008.

Plastic SCM

Plastic is a DVCS system designed with commercial use in mind instead of open-source projects (unlike Git and Mercurial). Plastic was first released in late 2006, featuring strong branching and merging, including full merge tracking and rename support in merges. It provides a highly graphical working environment, with many data-visualization capabilities, including a 3D revision tree). This distinguishes it from DVCSs that are oriented toward the hard-core, CLI-oriented hacker community.

The motivation of Plastic’s developers (BTW, I’m one of them) is to target small and medium teams, closing the gap between expensive high-end systems like ClearCase and low-end ones like SVN.

Plastic is built around the concept of parallel development, encouraging use of the “branch per task” pattern (feature branches). It can handle thousands of branches without breaking a sweat. Plastic is also distributed, supporting disconnected development, pushing and pulling of changesets on branches, and conflict resolution.

A Community Edition of Plastic SCM was launched in November 2010.

Team Foundation Server

Microsoft, wanting to play a role in the SCM/ALM market, came up with Team Foundation Server (TFS). It’s an effort to heal the pain caused by its own VSS devil.
While TFS is not very strong as a source-control system (kind of a new guy on the block, but using previous-generation technology), it comes fully packaged with a huge set of tools, from issue tracking to test management, in the pure “corporate-huge-integrated-thing-style”.

You won’t be doing branching, merging, or DVCS if you go for it, but maybe your company already purchased it, along with an MSDN subscription.

Concerto, a cross-platform .net profiler

2010-11-12T16:12:00.004+01:00

I'm going to introduce the basics behind Concerto, the cross-platform profiler we've developed to help us optimizing Plastic SCM.

The problem

The problem we face is simple: we need to optimize our code in Mono/Linux, Mono/Solaris, Mono/Mac and .NET/Windows. The best way to find issues is to run exactly the same test on the same hardware but with different OS (ok, Mac and Solaris are slightly more complex, right?, but for the main ones, Linux/Windows, the same iron will work), and then check the results.

We've been doing that for months but we always missed good comparable profiling data. You know, we do use things like AQTime on Windows and then the Mono Profiler on Linux but the generated data is not easy to compare.

We needed a different tool.

Let's start the music

We had the following idea: let's instrument the code to add some instructions to measure the time spent on each method, this way we can use the same instrumented assemblies to run with .NET and Mono and then we can compare.

Cecil was there to help doing the tough instrumentation part, so I emailed our resident Mono hacker: Dick Porter, and told him the idea. It took him a few hours to come up with a prototype, and has been refining it for the last week or so...

And, since it was all about instrumenting code... Dick named it Concerto.

Welcome Concerto

Here is how the toy works:


$ mono Instrument.exe --help
Usage: Instrument [OPTIONS] assemblies
Instrument one or more assemblies to
 record profiling data.
If only one assembly is specified, 
 instrumented assembly output name and
 data filename can be set.  Otherwise
 defaults are chosen for each assembly.

Options:
  -v, --verbose              Increase verbosity
  -h, -?, --help             Show this message and exit
  -f, --filename=VALUE       The filename where profiling data is written to
                               at runtime
  -o, --out=VALUE            The filename where the instrumented assembly is
                               written
  -p, --private              Include private types
  -c, --class=VALUE          The specific class to instrument (can be given
                               more than once)

Usage is pretty simple:

1) run Instrument.exe on an assembly of your choice
2) copy the output assembly back to your application, along with the generated Concerto-blah.dll
3) run your application
4) Look at the output file with mprof-decoder (or equivalent)

For example:


$ ls -l hello.* Concerto*dll *.mprof
-rwxr-xr-x. 1 dick dick 13312 2010-11-08 14:06 Concerto.dll
-rw-r--r--. 1 dick dick   384 2010-11-04 20:10 hello.cs
-rwxr-xr-x. 1 dick dick  3072 2010-11-05 16:51 hello.exe

$ mono Instrument.exe -vvv hello.exe
Instrumenting hello.exe, creating hello.exe.ins
The helper assembly is Concerto-hello_exe.dll
Data shall be written to concerto-hello_exe.mprof
Instrumenting class hello
Instrumenting method System.Void hello::.ctor()
Instrumenting method System.Int32 hello::DoStuff(System.Int32)
Instrumenting method System.Void hello::DoMoreStuff()
Instrumenting method System.Void hello::Main()
Done.

$ ls -l hello.* Concerto*dll
-rw-r--r--. 1 dick dick 13824 2010-11-12 11:53 Concerto-hello_exe.dll
-rwxr-xr-x. 1 dick dick 13312 2010-11-08 14:06 Concerto.dll
-rw-r--r--. 1 dick dick   384 2010-11-04 20:10 hello.cs
-rwxr-xr-x. 1 dick dick  3072 2010-11-05 16:51 hello.exe
-rw-r--r--. 1 dick dick  3584 2010-11-12 11:53 hello.exe.ins

$ mono hello.exe.ins
Hello, world!
1
1
2

$ ls -l hello.* Concerto*dll *.mprof
-rw-r--r--. 1 dick dick 13824 2010-11-12 11:53 Concerto-hello_exe.dll
-rwxr-xr-x. 1 dick dick 13312 2010-11-08 14:06 Concerto.dll
-rw-r--r--. 1 dick dick   365 2010-11-12 11:54 concerto-hello_exe.mprof
-rw-r--r--. 1 dick dick   384 2010-11-04 20:10 hello.cs
-rwxr-xr-x. 1 dick dick  3072 2010-11-05 16:51 hello.exe
-rw-r--r--. 1 dick dick  3584 2010-11-12 11:53 hello.exe.ins

Now let's inspect the output with the mprof-decoder


$ mono mprof-decoder.exe concerto-hello_exe.mprof

------------------------------------------------
Reporting execution time (on 4 methods)
97.19% (0.007282s) hello.System.Void hello::Main()
 2.48% (0.000186s) hello.System.Int32 hello::DoStuff(System.Int32)
        1 calls from hello.System.Void hello::Main()
        1 calls from hello.System.Void hello::DoMoreStuff()
 0.33% (0.000025s) hello.System.Void hello::DoMoreStuff()
        1 calls from hello.System.Void hello::Main()


------------------------------------------------
Reporting execution time by stack frame
97.19% (0.007282s, 1 calls) hello.System.Void hello::Main()
     2.33% (0.000169s, 1 calls) hello.System.Int32 hello::DoStuff(System.Int32)
     0.34% (0.000025s, 1 calls) hello.System.Void hello::DoMoreStuff()
        66.67% (0.000017s, 1 calls) hello.System.Int32 hello::DoStuff(System.Int32)

Finally an example of picking classes to instrument would look like this:

Get the list of classes with verbosity level 2:


$ mono Instrument.exe -vv plastictcpchannel.dll
Instrumenting plastictcpchannel.dll, creating plastictcpchannel.dll.ins
The helper assembly is Concerto-plastictcpchannel_dll.dll
Data shall be written to concerto-plastictcpchannel_dll.mprof
Instrumenting class Codice.Channels.ClientSinkProvider
Instrumenting class Codice.Channels.ClientSink
Instrumenting class Codice.Channels.PlasticBinaryServerFormatterSink
Instrumenting class Codice.Channels.PlasticBinaryServerFormatterSinkProvider
Instrumenting class Codice.Channels.PlasticTcpChannel
Done.

Pick a couple of classes to instrument:


$ mono Instrument.exe -vv -c
  Codice.Channels.PlasticBinaryServerFormatterSinkProvider -c
  Codice.Channels.ClientSinkProvider plastictcpchannel.dll
Instrumenting plastictcpchannel.dll, creating plastictcpchannel.dll.ins
The helper assembly is Concerto-plastictcpchannel_dll.dll
Data shall be written to concerto-plastictcpchannel_dll.mprof
Instrumenting class Codice.Channels.ClientSinkProvider
Instrumenting class Codice.Channels.PlasticBinaryServerFormatterSinkProvider
Done.

Enjoy!

Branch explorer tour

2010-11-08T23:42:00.007+01:00

It's been a week since we announced the Community Edition and a big number of developers have already downloaded and started to work with Plastic.

People are coming from different SCMs and jumping into Plastic: developers with CVS background, experience with SVN, Mercurial, Git and even Clearcase and TFS. So, this is a really heterogeneous group.

My intention today is to focus on one of the key features in Plastic: the branch explorer. This is to help the newcomers can really extract the best out of our SCM (our former users are already more than familiar with it, or anyone attending a demo).

So I just recorded a short screencast showing some of the key functionalities within it. Almost everything is doable from the BrEx (as we call it internally), and you guys should get familiar with it!

Here we go (I recorded it in high-res so configure your viewer accordingly):

Mylyn integration

2010-11-04T14:20:00.009+01:00

One of or key goals with the new release is to continue improving Plastic SCM support for the Java/Eclipse ecosystem.

The new release includes a number of important improvements on the core Eclipse integration (such us the new Synchronize view, the ability to directly import projects from Plastic SCM during workspace creation and revisited check-in functionality) and the totally new Mylyn integration to improve parallel development within Eclipse.
The Mylyn integration represents a significant step for Codice as it will streamline parallel development for Eclipse users.

New Mylyn integration

Mylyn is the task and application lifecycle management (ALM) framework for Eclipse and as such is all about creating a task-focused interface for developers. Plastic SCM is designed to implement a task-oriented cycle through extensive use of parallel development with branching and merging. It is clear that the two tools can team up perfectly to create a really strong task oriented environment.

One of the Mylyn limitations when the underlying version control system has limited branching capabilities (as it happens with Subversion, CVS or Perforce) is the ability to correctly manage overlapping changes: What if two different tasks have to modify a colliding set of files? Mylyn, due to the SCM (Software Configuration Management) limitations, is unable to correctly handle the situation unless the changes on the task are committed prior to the switch to a different task. So, having simultaneous open tasks with pending changes is troublesome.

The Plastic SCM Mylyn plugin resolves the issue by extending the basic Mylyn functionality and associating each task with a different Plastic branch, hence implementing real parallel development and powerful isolation between branches.

As the following figure shows, when the developer activates a different task, the Plastic SCM Mylyn plugin is able to assist the user to create or switch to a different branch, associated to the mentioned task.

Task to branch association can’t be simpler nor more effective than the way the new Mylyn plugin implements: the entire branch management is driven by the tool, assisting the user at every step.

Plastic SCM integrates natively with a number of issue tracking and project management system like Atlassian Jira, FogBugZ, Mantis, VersionOne, Rally, Bugzilla and others. Now the integration and task visualization is also available from the Eclipse side as it is from the GUI. The following figure shows the Plastic SCM graphical user interface running on Ubuntu Linux integrated with Jira.

Eclipse plugin enhancements

There are several new features on the core Eclipse plugin for Plastic SCM, all focused on improving the general usability within the IDE.

The first functionality to be described is the new synchronize view, available from the team menu.

The new synch view introduces an alternative way to perform checkins of pending changes, more familiar than the former checkin dialog especially for Eclipse users previously using Subversion or CVS.

The team synchronization view allows an easy navigation and review of the pending changes and also enables an easy way to commit all changes together.

The second important change introduced by the release of this reviewed Eclipse plugin is the new checkin pending changes dialog, improved to match the user’s expectations.

Finally, we’ve added a new import option to the IDE so developers can easily configure new workspaces directly downloading the code from Plastic as they’d do using Subversion or CVS.

The import wizard will drive users through the workspace creation process and will also help selecting the repository and branch or label to work on.

Download and try!

It's been only a few days since we released the Community Edition, which as you know is free for small teams (up to 15 developers!). Interest is pretty high and we expect Eclipse users to be taking a look at Plastic too with this new enhanced plug-in.

So, you know: spread the word!! Tell every one Plastic is now free and they can start using it asap at no cost!

Plastic 3.0.7 is out!!

2010-11-01T21:19:00.010+01:00

Together with the launch of the new Community Edition we're announcing a new version ready to be downloaded: 3.0.7! And it comes loaded with new features: new Visual Studio integration and Mylyn integration for Eclipse users.

Our policy is to release a couple of major releases a year, but our dev team is so active and there are so many ideas floating around that we need to publish new features more often than that.

That’s why after we released 3.0 a few months back, instead of just “retaining” new features for the next major version, we’re just publishing them on a frequently basis.

And that’s why today I’m announcing a good number of new features in 3.0.6, together with some fixes and customers requests.

You can find all the details in the release notes, but let me explain in a little more depth what’s 3.0.7 is about.

New Visual Studio integration package

Visual Studio is one of the most used IDEs by Plastic SCM users out there and that’s why we’re trying to continuously improve our integration with it. As part of the new release, we’re introducing a new Visual Studio Package for Visual Studio 2005 and higher. The new package allows our customers to implement full SCM operations.

Why are we coming up with a new package? Here are the reasons:

We had originally offered very basic SCC integration, which is still maintained and enables compatibility with older versions of Visual Studio. However, getting rid of the old SCC limitations which will enable us to continue evolving the integration rapidly and without meaningless restrictions.

We are now able to add more integrated functionality: checkin behavior is now shared with the GUI, the same happens with the access to all the GUI views and so on.

We have created a better base to continue evolving plugins and enable more innovative functionalities. We’re considering a bunch of ideas to extract info in real time from the SCM and make it available while the programmer is coding, helping him to make the right decisions. Stay tuned because there will be a lot more coming.

Now let me describe in bigger detail how the new package looks like

Configuring the new Version Control Package

Going to Tools/Options you’ll be able to select the new “Source Control Package.” Keep in mind that you can choose from the old SCC or the new one, it’s up to you!

New context menus available

Thanks to the new integration we were able to include much more functionality in the Visual Studio IDE.
Look at the new context menu options that were simply not available before, like annotating code or showing up history and tree 3D (before only the tree was available).

All the views in the Plastic GUI are also available from View/Plastic SCM menu (it was there also in the former 2005 package, but now we added a “workspace explorer” too).

Integrated history

Several users requested it in the past and in fact it is something we must have added long ago. But finally the history of an item can be browsed from within Visual Studio.

Integrated annotate

The annotate is now available within the Visual Studio IDE.

New pending changes view

The checkin window is now shared with the GUI, displaying the “pending changes” dialog.

Integrated diff

We’ve made several changes in the diff infrastructure for 3.0.7 and now there’s a new configuration page on the wizard to let you set up the diff tools.

You can choose the “embedded diff viewer” (new) or the Plastic SCM diff tool (the default) or set up your own diff tool.
In case you go for the “embedded” one the diffs will be displayed as follows in the GUI and Visual Studio.

Hope you enjoy the changes!!!

Building Plastic SCM's Community With a Community Edition

2010-11-01T21:01:00.010+01:00

We're just announcing a Community Edition of Plastic SCM. We will license Plastic SCM for free to environments with up to 15 developers, which will cover a huge percentage of the development teams.

For the ones new to Plastic SCM:

It is a distributed version control system that can act as a centralized one too

It is very, very strong doing branching and specially merging (no issues with renaming, full merge tracking, visual merge diagrams (branch explorer), 3D version tree and many more). It does include tools like xmerge and xdiff, the only "refactor aware" diff and merge tools on the market.

It focuses on visualization: from the branch explorer, the 3D version tree, the view based GUI, integration with Visual Studio and many more

We now have hundreds of customers whose developers rely on Plastic SCM to manage and overcome many of the challenges related to distributed development. We hear from our users often, and that feedback is very important to us. We want to build a community of Plastic users who exchange information about the product and their successes, while giving us constructive feedback on the product.

The new edition aims to build our community. With the new licensing, our customers receive a full-featured version of the product, with all the bells and whistles one receives from our enterprise licensed version. Our customers often tell us that Plastic is the only product out there that can handle merging of distributed code while providing an easy-to-use graphical interface. Our interface is not an “add-on,” it’s a cornerstone. We built Plastic with things such as visualization, usability, advanced diff and merge tools in mind. And now the full features of Plastic are available to small teams for free.

Community edition customers will be able to subscribe to priority support in case they need further assistance than what our user community forums will provide.

We invite all developers to use Plastic SCM for their smaller projects by capitalizing on the community edition licensing. We then invite you to visit and contribute to our forums.

For more information, visit the community edition product page, which also leads to a FAQ.

Also today, we're introducing new enhancements to Plastic SCM, as outlined in two additional blog posts.

Eat your own dog food

2010-10-27T19:11:00.003+02:00

Yeah, that's what we're doing, eating our own dog food.

We just migrated our Plastic SCM internal server from an old Fedora Core 4 (yes, that oold... but is our server and we love it!) running on x86 hardware (Xeon) to a SPARC Solaris 10 box. A big endian 64 bits SPARC box!! :)

The previous configuration was running Mono + Bohem GC and Plastic storage was an external Oracle database (yes, separate Plastic and database servers, again, eating our own stuff), and now the configuration is as follows:

SPARC Solaris 10 server

Mono 2.8 + sgen (yes, sgen!!!)

Plastic SCM 3.0.7+ (internal build, not out yet)

SQL Server 2005 external database (yes, no make things even funnier we're using a little-endian db :P with a bigendian system, in fact we found a bug in our GUID conversion code while reusing the old db, something that wouldn't happen if you create your dbs with the bigendian server, would only happen if you plug 'old' databases created by littleendian boxes to it).

So far the old iron is behaving really well, it's only been one day in real production (after weeks of load testing and so on, of course) but no known issues yet. It's not as fast as our previous server but that's because we're not using very strong hardware. I'd like to see it working on a beat like this.

Although obviously SPARC hardware is not the most demanded at all, we're committed to support it since specially big customers tend to ask for at least a few servers running it... It's been supported for years already but now we're really about to have better packaging and so on, I expect to have an installer on the coming weeks (so far we installed manually).

Will let you know how it goes... :P

Mono 2.8 available for Solaris 10 SPARC and x86

2010-10-21T21:29:00.007+02:00

We've just released (thanks to Dick Porter, our resident mono hacker, who had to make some fixes on the sgen implementation to make it run on SPARC) the Mono 2.8 packages for Solaris 10 (x86 and SPARC) and OpenSolaris.

They're available to download here: http://www.go-mono.com/mono-downloads/download.html

Installing the packages is not hard, just a matter of playing with pkgadd after downloading them. It will warn you about missing dependencies and so on. I installed the SPARC ones yesterday on a clean box and there are the ones I had to download (from sunfreeware.com) and install:

libgcc-3.4.6-sol10-sparc-local

libiconv-1.13.1-sol10-sparc-local

libintl-3.4.0-sol10-sparc-local

And then I was able to install mono successfully.

Mono installs (by default) on /opt/mono so here's what I use to launch it: LD_LIBRARY_PATH=/opt/mono/lib /opt/mono/bin/mono

How did we test it?

We run our entire PNUnit test suite on Solaris to validate the build (and Plastic) and we also run load tests for days using a Solaris SPARC server (both with Boehm and sgen (MONO_GC_PARAMS=major=copying LD_LIBRARY_PATH=/opt/mono/lib /opt/mono/bin/mono --gc=sgen) with very good results.

As a side note, this Plastic server that you see up and running is using a... SQL Server database as backend... so, yes, the Mono SQL Server implementation works even using bigendian software!! :)

MWF is available too

We've included the libgdiplus library. It is stable on OpenSolaris but we weren't able to make it stable enough on Solaris yet. Just time to get some nice screenshots!

Future

We plan to continue building and supporting Mono on Solaris, both x86 and SPARC, since it is key for some important deployments.

Side notes

This 2.8 Mono release is the most "multi-platform" I've seen so far. I'm able to successfully run the entire Plastic testsuite under Solaris (x86 and SPARC), FreeBSD, OpenBSD (first time I'm able to do it!), Mac OS X (both PPC and x86). So... yes, expect some default packaging on OpenBSD in the coming months!! :)