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?

It is Monday morning and we find the developer on his way back to his desk. Cup of coffee in hand to fight off the mid morning slump, he suddenly realized he was not alone. With a glance to his left, he finds his boss flanking him. “You always claim that where there is double entry, you can find a better way. Well I think our shipping team has a challenge for you.” announced his boss.

The developer didn’t know much about the shipping process. He knew that shipping transmittals had been created in Virtual Ticket. These documents included all the details about the shipment: Recipient, address, shipping method, priority, contents, tracking number, and all was manually entered. The transmittal is filled out by the project manager and a printout routed with the package contents to the shipping department. But now it was time he learned about the rest of the process. He decided to spend the day in the shipping department to get some first hand experience.

In his company, FedEx is the preferred parcel courier. They use FedEx Ship Manager, an online shipping solution, for creating the shipment transactions. At the close of each business day, one of the office clerical staff exports a list of packages that shipped through the FedEx online account. That list is then photocopied and distribute to each project manager and production manager. This provides the project managers with the tracking numbers of all of their packages, just in case they get a call from a client.

The developer cringes as he learns about this process. He recites his mantra: "Every time paper is used to distribute database data, another tree dies”. In someway he feels his neglect is responsible for this. As the day goes on, he learns more about shipping software applications and he identifies many opportunities for integration to his Virtual Ticket system.

The next day the developer got to work and by noon had developed some solutions that he was anxious to show his boss. After lunch they had a quick meeting: “The daily export of data from the FedEx online account can be easily imported into Virtual Ticket. Using this Virtual Ticket import form I created, the FedEx Tracking number is imported right into the tracking number field on the Virtual Ticket shipping transmittal. And, since we have our client’s email addresses in Virtual Ticket, I have also included script to automatically send the clients an email of the shipment information. The clients get confirmation that their package has shipped, the contents of the package and the tracking number.”

At first his boss looked pleased but that look soon passed. “Looks like that should take care of their current needs but I was expecting to be more amazed.”

“Well, I have also added some other functionality.” the developer responded. “The project managers had been going to FedEx.com where they would manually enter their tracking numbers. Now, with the new MetaScript OpenWebPage() function available in Workgroups R2, I was able to add a button that will open the FedEx tracking web page right in Virtual Ticket with the tracking number already entered. The project managers can now get up-to-the-minute tracking results with one button click, and never leave Virtual Ticket.”

His boss smiled with satisfaction “That is more like it. Good job.”

The developer continued, “You know, most parcel shipping applications allow for importing and exporting data but I also found that most can support a live connection to other databases. We could setup a connection between Virtual Ticket and our shipping application to share common data. The shipping application could then access Virtual Ticket for current Customer contact and address information. Then the tracking numbers could be written back to Virtual Ticket without human intervention. I think I will look into developing that functionality next.”

With the ability in Virtual Ticket's SQL database to establish live connections to other databases, there are endless possibilities to eliminate double entry, stop printing database data and save another tree.