Sneak peek of improved version control management for Iguana 6…

It’s a good rule of thumb that if you are going to make something better – it’s just as costly to make something 5% better than to make it ten times better. I think the rework of the source code control system in Iguana 6 is going to be ten times better!

I’ve attached some screen shots which show the commit workflow. There are a number of improvements in the design.

Rather than having pokey little commit dialog the commit process uses the entire screen real-estate. You have the choice of which files to commit into repository. By selecting each file you can see what has changed in each file in the panel on the right which is updated depending on what file you have selected. There are a few views supported in terms of horizontal vs. vertical diff format.

Where the solution really starts to excel though is how it makes it possible to look what what other projects are affected by a change to shared module.

If you notice the project in italics “04 -Test Data Generator (From Translator)” this project is in italics because it has other changes pending – so it will require a manual process to update that translator instance. For the others though it will be possible to bump them up in their version and bring them along for the ride.

All that adds up to massively improved work flow for handling shared dependencies.

Iguana 6 also allows translator instances to have multiple non shared modules – under the hood the mechanism for defining ‘milestones’ is being greatly simplified to avoid the current tagging which happens.

It will also be possible to use a single repository for multiple Iguana instances. We plan to support GIT and are looking how whether to completely change over to just using GIT or whether we should retain the fossil functionality – obviously we will provide mechanisms to migrate to the new structure.

Native support for GIT will mean being able to leverage all the eco-system which exists with GIT hub, bit bucket etc. making it more convenient for large teams and geographically distributed teams.

Attachments:

You must be logged in to view attached files.

If you have a look at the filename_highlighting.png attachment you’ll notice that the UI shows which project are affected by the change to a particular module.

Eliot,
This looks really exciting! Can’t wait to see more. Although I do like the simplicity of Fossil built into Iguana and not having to think much about what your doing with the versioning. I like the idea of having have multiple non shared modules in the translator if I am understanding what that will allow me to do. I currently use your Channel Manager and GIT with Bit bucket to store my projects. We use it for our application development as well and can see the value and flexibility incorporating that will offer.

We should be able to retain the simplicity aspect for the typical usage. There are some good options now with GIT which allow one to statically link in GIT support into an application (without triggering the GPL shotgun – good bye iNTERFACEWARE as a company lol…)

Whatever we finally end up choosing the intent is to have source code control out of the box with Iguana – it would be lousy to have to go and install a bunch of tools which each Iguana install.

One thing that is very handy with fossil from our support point of view is the ease in which we can have a user email us their vcs_repo.sqlite file and send it to us. Since we have to distribute fossil with Iguana anyways at the minimum for back converting existing installs one idea we’ve had is using that to make a button in Iguana can could be used to package up the whole Iguana configuration so that it could be emailed to support.

Bret is doing a great job looking at the whole system from a complete perspective just looking at the typical kinds of things people need to do.

One neat thing that will drop out of all this is that we oughtn’t to matter if power users want to get down at the command line and use more advanced features of source code control like branches and so on.

The non shared modules is already in the nightly unstable branch snapshot that is publicly available.

Anyways happy to discuss and chat about what we are doing with this – it’s an easy time for us to make changes since it’s a major release where we can make big jumps in functionality.

I’m so glad to see a list of channels that use the shared module. I’m also looking forward to non-shared modules.

Hi, there is one functionality I am missing much also related to version control – “all channel update with one button”. In my case I have a share module/s with frequent updates and more then 20 channels using it. Every time I need to implement my changes I must save milestone and restart each channel – usually it takes more then 40 minutes – painful and error prone activity.

Rafal

Hi rafal,

One option (until Eliot supplies this feature ;)) might be to script the process using the Iguana api using curl. You could get the channel list, then start/stop each channel through the api.

Jeff Drumm ◊ VP and COO ◊ HICG, LLC. ◊ http://www.hicgrp.com

This is actually one big motivating reason as part of the whole do-over of the source control integration.

If you look closely at the attached screen shots you’ll notice that it shows a list in the bottom left pane of translator projects that are impacted by a changed module. The work flow is pretty sweet because you can select a particular shared module in the top left pane and it will even highlight which translator projects are impacted.

If those impacted translator projects don’t have any other changes pending the idea is to allow you to update those projects from within this dialog. The next stage after this dialog which isn’t shown is the screen which then gives you the opportunity to bounce all the channels which have been impacted by the change. We’re still playing a little with whether that can be done with a good work flow within the one screen or if it needs a second screen after the commit to manage that bounce of the channels.

If the other translator instances do have other changes pending then the idea is it will be a manual workflow to go and examine those instances to see if it is safe to update them or not. To make that a more convenient workflow as part of the project we’re putting some attention into improving the little badge icons that we see in the dashboard to have a better algorithm in terms of distinguishing between when there are uncommitted changes sitting within the sandbox of a translator instance and when a translator instance is running a version that has one or more shared dependencies that are not up to date. We’re hoping to also give a little bit more visibility into what is resulting in that status icon from tooltips in the dashboard.

This is really a major rethink of this whole system based on thinking very hard about the work flow issues that we’ve discussed and seen from our user community. We’re taking the time to get it really right.

Anyways happy to know we’re on the right track! It’s helpful to get the feedback and be able to explain how this solves these types of problems.

Jeff – one thing we are still missing is to save milestone on the fly 🙂
But good to know this will be available soon (hope sooner than later).

Do you have a rough timeline of when you expect to have these changes available?

Hi Paul,

Obviously it’s not a really clever idea to nail down a date too precisely, because the development process is full of both joy and tears. But the progress is good and so is the mood.

So: Months not weeks, but not too many months.

I hope that’s not too vague an answer. We’re very excited about what we’re building here, and it’s nice to see our users sharing that.

That answer works. We are in the progress of converting our interfaces from VMD based to fully translator based to leverage the shared module capabilities. However, we have 4 instances that have about 25-30 channels each and each one requires some level of specific customization in the main file.

From the sounds of it, the changes in Iguana 6 should help ease some change control and deployment processes, which we still havent fully hashed out.