Posts Tagged ‘Svn’

All The Young (Ex) Dudes

February 9, 2010

As we near the end of beta here at Mike HQ, I’d just like to publicly say a big thank you to all our participants who have helped to shape and improve our platform over the past few months – your feedback has been invaluable.

We are currently in the final phases of testing the version of our platform that will form the basis of our commercial offering. Our acceptance testing work flow involves consuming services provided by other organisations to best simulate a real-world usage scenario for our platform. The primary third party service we use is hosted version control. In fact, it is only reasonable to state that Mike has a strong dependency on the existence of such services. It is the first link in the chain of what we here at Mike HQ refer to as the ‘hosted ALM continuum’ – the suite of co-operating and complementary hosted services that provide agile teams with a full outsourced, web-enabled, development ‘stack’. Disclaimer: it is most definitely in our interest to promote hosted version control solutions, as they are an enabler for the use of our own platform.

So, what do we use for testing?

Well, at present we support Subversion repositories that are accessible over Http(s). To simulate repositories that do not require authentication for read access we use Google Code. For those who are unfamiliar with Google Code (there can’t be that many of you surely?) it provides a free collaborative development environment for open source projects, and provides each project with its own Subversion repository. Thanks, Google.

However, our main scenario is retrieving (or updating) source code from repositories that do require authentication and also provide a secure transport using Https. After surveying the landscape, we decided to trial a service offered by Codesion. At the point we signed up (last year) they were known as CVSDude and they have recently re-branded themselves under a new name. We did like the old name – it has allowed us to indulge in some office banter during our acceptance testing phases, which, lets face it, are often not one of the more exciting aspects of software engineering. I won’t bore you with our banter though as it probably falls into the camp of ‘you had to be there’ to seem even remotely funny.

Codesion web site

Codesion

Setting up a free 30-day trial on Codesion was a cinch:

  1. We swiftly signed up via their website, http://codesion.com/
  2. We created a new project, and added the Subversion service
  3. We created our users, groups, roles (they have a bunch of defaults), and assigned them to our project.
  4. We cut-n-paste’d the SVN URL from the project page, into our SVN import statement and we were done.

At this point we now had data we needed to test our platform – our test fixtures are a range of Java projects of different flavours. A side-effect was that it definitely gave us a view of what a slick SaaS sign-up process and after sales care looks like – something for us to aim for with our own offering. Since we started using them we’ve had zero problems. In some of our test cases we hit the repository repeatedly and it gives us the same reliable service every time.

We’d have no hesitation in recommending Codesion if you are looking for a low-cost, industrial-grade hosted solution for Subversion. But, if you are reading guys, we did slightly prefer the old name….sorry ;-).

Why DVCS won’t kill Subversion in 2010

January 21, 2010

At Mike HQ we are currently implementing support for GitHub as this has been requested by a number of our private beta participants. We like Git and are currently undergoing an internal debate/argument as to whether we should switch (no pun intended) to a DVCS from Subversion for our own source code management.

I was going to write something that discussed why, although we might decide to use Git ourselves, it isn’t suitable for everyone – I firmly believe that Subversion usage will continue to thrive in 2010.

However, after searching some, I discovered a comment from this blog entry which more or less summed up my own thoughts. I’m simply going to reproduce it here verbatim (courtesy of clr_lite whoever you are):

  • distributed version control is not for everyone
  • too many people are enamored of a tool or something because it’s new
  • every organization has it’s own situation and needs
  • getting a full repository and allowing people to work in silos without collaboration is not necessarily a good thing
  • git addresses the needs of linux kernel development, with many contibutors funnelling to a gatekeeper
  • some development shops benefit from a locking checkout model which forces developers to communicate and plan
  • subversion has a lot of users and knowledge pool; this can be important for some situations
  • distributed model has it’s plusses; getting all the history, changes, diffs, etc, while offline can be real helpful, but it all depends on the nature of the development and the developers
  • no one tool or process is ‘right’ for everyone

Well put, I thought.