We're launching BL707 today and it includes one highly awaited feature: the Linux GUI now includes its own native 3-way mergetool (a.k.a. gtkmergetool).
Hi there! My name is Göran Wallgren and I was invited to write this guest blog post to share how we switched our version control system from SVN into Plastic SCM. I work at Surgical Science (Sweden), where we have been developing products for medical simulation training for more than 15 years.
We started out using CVS for version control, and then migrated into SVN (Subversion) and TortoiseSVN almost 10 years ago. In summer 2015 we finally decided to migrate into Plastic SCM. Besides the advanced merging and handling of large binary files, one of our main reasons for choosing Plastic over Git or Mercurial was that it can work both centralized and distributed (DVCS), which made the switch from SVN easier. The changeset numbering scheme is also closely resembling the one in SVN.
At the point of migration, we had close to 28000 revisions from 14 years of code and data history in our main SVN repository (ca 20 GB). We wanted to keep all revisions from trunk but decided to leave out inactive branches in the import and also to split some parts into separate repositories in Plastic. In the end, this left us with a bit over 17000 imported changesets in the main Plastic repo.
Migration would have to go via Git, since Plastic won't import directly from SVN. Earlier, one had to use Git fast-export and Plastic fast-import which had some issues (mainly since Git does not log directory removals in the fast-export file). However, that has all changed with the Plastic GitSync feature that means Plastic SCM can now speak directly with Git over the HTTP/HTTPS and GIT protocols.
Besides the actual import of the data, we needed to find ways to replace some of the features we had been using in SVN, mainly svn:externals and the SubWCRev tool from TortoiseSVN. At the end of this post we'll give some useful tips regarding this.
You're coding on your laptop (anywhere but the office), you checkin to your local repo, and then you want to share it with your colleague bob for a quick review.
One option is to go and push to the central server, then ask bob to pull from there. Not bad, the usual cloud based server placed somewhere.
Another option is to find out bob's public IP address, ask him to tweak the router so his Plastic server becomes reachable and... well, we won't go that route…
Wouldn't it be just awesome if you could simply do something as follows?
Locate bob's repo just using his email, no matter where he is, as soon as he is connected to the internet.
This way it won't matter whether you both are behind firewalls, or if you switch locations, you'll be always reachable.
This way to reach Plastic SCM servers is what we called The Tube and we opened it up for beta testing back in May 2015.
Following our path towards a semantic version control, we are totally aware of the great number of programming languages out there. Even if we natively support popular languages –such as C#, Java or C– we can't expect to cover all that ever-growing vastness. But we wouldn't like to let the Plastic SCM community think we've forgotten about them, either.
This is why we've allowed external language parsers to be plugged into Plastic since release Plastic SCM 184.108.40.2069. Now, developers can collaborate with the community to implement custom parsers, which means support of virtually any possible language! There are, however, some rules that all custom parsers must follow in order to successfully communicate with the Plastic SCM semantic version control engine.
Take a look at the outcome:
Wouldn't you love to have this kind of information right on your version control GUI? Keep reading, then!
Google Cloud Messaging is, for those of you who don't know it, a free service that allows developers to send real time push notifications across different platforms, like Android, iOS, and Google Chrome. It is reliable, easy to implement both client and server sides, and it's fast.
So, while I was implementing GCM in a pet project of mine, it came to my mind that it could be useful for someone to have in their handheld device, or in their browser, real-time updates about what is happening in their team through their favorite DVC software.
You refactor some code before doing a bug fix, you clean it up to better understand how it works, and leave the code in a better status than you found it, in purest boy-scout style :P.
Then you move methods to a new class in a new file. And later make some modifications to the moved methods. Easy, uh?
Well, Plastic SCM can now track the refactor and diff it correctly, because we have just implemented multi-file semantic diff or "analyze refactors":
This is another step forward towards semantic version control as we explained about one month ago with our initial release.
Now Plastic can track moved code across files, and soon we'll apply the same tech to merging.
The new release we’re announcing today, BL677, includes a feature that pretty much explains what our vision for the future is: semantic version control.
It may sound like big words but it is a pretty simple concept: the version control “understands” the code. So when you diff C#, Java code, C, VB.net (and hopefully all languages in the near future), it knows how to handle it:
- The version control timeline
- Towards Semantic Version Control
- Designing a better user experience
- Linus on branching...
- Merge recursive strategy
- The fastest way to insert 100K records
- Put your hands on a programming-language-aware, refactor ready, merge tool
- Linus Torvalds on GIT and SCM
- The state of the art in merge technology
- Cherry pick vs merge
- best practices
- branch explorer
- continuous integration
- custom parsers
- google cloud messaging
- version control
- visual studio