Using a Version Control System (VCS) to Manage Virtual Ticket DevelopmentΒΆ

This developer blog article was originally published on MetaCommunication’s website in September, 2010 and illustrates how Mercurial (or other version control systems) can be used to manage development within Virtual Ticket.

The original article is no longer accessible on MetaCommunication’s website, but the text has been preserved below.

Workgroups 2010 R2’s ability to export unpacked library files enables you to begin managing your Virtual Ticket development through a third-party version control system (VCS).

Over the past few weeks, I’ve been experimenting with a new feature of Workgroups 2010 R2: specifically Virtual Ticket’s ability to export “unpacked” library, or .vtl, files and how they might be managed with a third-party version control system (VCS).

As a brief background, Virtual Ticket has always maintained the ability to export structural elements (forms, finds, etc.) to a library file that can then be imported for use in other Virtual Ticket databases. This is most commonly done when moving forms from a development database to a production database. The original file extension used for these files was .osf. This was later replaced by a .vtxml file as Virtual Ticket began exporting library files into an xml file format. With Workgroups 2010 R2, a new .vtl file format has been adopted, which expands on the amount of structural elements that can be exported to include not only forms and finds, but also user groups, application menus, and much more. With the .vtl file format, Virtual Ticket enables users to export the library file either as a single, “packaged” file, or as an “unpacked” library which will generate separate .xml files for each form, find, type, etc.

The advantage of being able to create unpacked library files is that it is now much more feasible to begin managing Virtual Ticket development through a version control system. There are numerous VCS systems readily available; some of the more common ones are Mercurial, Perforce, Subversion, Bazaar, and more. Regardless of which system you prefer, the concept is effectively the same - you can manage versions of files (the individual .xml files that comprise an unpacked .vtl library) across multiple developers.

After experimenting with several VCS systems, I’ve settled on using Mercurial as the underlying VCS system while using MacHG as the graphical user interface. (A similar, popular GUI to Mercurial is also available on Windows called TortoiseHG.) In my environment, I’ve created an initial project containing the entire contents of my Virtual Ticket database structure - all the forms, finds, groups, etc. as an unpacked export. I initiated this as my core project within MacHG, with it residing on a shared network drive. I then “cloned” this project to create my own personal working version which resides on my own personal desktop Mac (though this could also be on a shared drive as well). The advantage of having the core project on a network drive is that then multiple Virtual Ticket developers can create their own “cloned” versions of the project.

With individual “working versions” of the core project, each developer has the same starting point to work from, and can import into Virtual Ticket whichever structural elements they need based on what areas they are going to work on. When they have completed their additions/modifications, those can be exported as unpacked files and brought into the working version of the project, and then when appropriate can be merged into the core project as well.

With my initial experiments, the biggest advantages to using a VCS I’ve found so far include:

  • Manage Virtual Ticket development across multiple developers simultaneously
  • View differences between files to easily identify what was changed, when it was changed, and by whom
  • Rollback to prior versions of files
  • Develop new solutions or modify existing solutions without impacting the core project until ready to do so
  • Identify how many and which files need to get pushed or pulled to sync with the core project

I’ll admit that using a VCS to manage Virtual Ticket development is a newer area for me, and I’ve discovered some tricks and tips that work well with MacHG specifically. But I’m really excited and encouraged by what I’ve experienced thus far, and I’ve love to hear about your experiences with Virtual Ticket and version control systems. Do you use any type of VCS currently? Are you considering it?