Hansky, Help Better Software

Offline Development using Firefly

Technological background

What is disabled?

Things to bear in mind

What Do you get in offline mode?

What is offline development?

Offline development, sometimes referred to as disconnected development, is the practice of developing a project in a controlled environment without network connections or the network connections are intentionally made unavailable to the configuration system for various reasons.

A configuration system with offline/disconnected development support should have the following characteristics:

Ability to maintain data integrity in offline/disconnected mode
Work done while in offline/disconnected mode should be preserved and merged back without losing data or corrupting existing data.
Ability to save multiple file versions in offline/disconnected mode
This is a vital, not to mention convenient feature. The most essential functionality of a configuration management system is to record development history by establishing base points (i.e. file versions). This should not be degraded.
Separation of client and server in offline/disconnected mode
While in offline/disconnected mode, the client end should not communicate with its server, while still be able to maintain the first two characteristics. Some of the existing CM systems uses local server to achieve the same goal. That is a work around, not offline/disconnected development.
Automated merging mechanism
When going back online, the work did when away from network connection should be merged into development stream automatically. The process might need human intervention because of conflicts but that should be it.

Why offline development?

Because you cannot or the situation makes it impractical or inefficient to get "online".

Most of the version control or configuration systems use a client-server structure which requires the client end to communicate with a server on a regular basis in order to ensure data integrity, smooth operation and team collaboration. Obviously, this mechanism involves some kind of network connection.

Then why is offline development necessary? There are several scenarios in which you will find offline development support from your configuration management system is more than welcome. For an instance, you may find yourself on an airplane and want to get some work done, yet still be able to keep all the history and more importantly, merge them back to the parent branch later. Or, you might be working with collaborators from all over the world who prefer to submit their changes periodically rather than being connected to the server at all time.

Firefly offline development support

Offline support in Firefly requires no complex command, no replication of repository, no creation of private branch or local server. With just a switch of an option, you are all set for disconnected development in what we call Offline Mode.

If you are using Firefly command line interface, the command to toggle Offline status is:

hff set hansky.firefly.offline.status true

While in offline mode, all history and changes will be preserved, including Move/Rename operations. And the process of merging these offline operations back to the stream is automated and effortless.

Technological background

The reason why offline support comes so easy and natural in Firefly is due to its excellent infrastructure. Let’s look at the following diagram for a very basic idea of how Firefly works.

Local workspacesLocal Workspace:

Local Workspace is also referred as Workspace in Firefly. Local Workspace is stored on your hard drive as a directory on the local file system. It serves as a private working area where the owner has total control over its contents.

The concept of local workspace is essentially why offline development is made so easy and powerful in Firefly, although the actual implementation is much more complicated and involves all component of Firefly. deal with their respective staging workspacesStaging Workspace

Staging Workspace is a server-side mirror of your Local Workspace or your private stream on the server. It contains not only the contents of the files in your workspace, but also the histories and changes you made.

Staging Workspace will hold your changes until a Submit command is issued at which point these changes become part of the history on your staging workspace and are merged to the parent branch. directly and then staging workspaces relay data to the branchBranch

Branch represents a development track of a project. It is also often referred as stream or codeline. A branch is usually created using a product baseline as foundation.

Branch in Firefly is based on projects instead of the more traditional file-level branching. FleXtream is the technology behind Firefly branching. Branches are stored on Firefly server, created and managed by Firefly branch administrator. Firefly branch administrator configures ACL for each branch, manages label, branch comparison and merge., after computation and manipulation of course. When you work in your workspace, every command is send to your staging workspace on the server to keep these two in sync. And depends on which commands are executed, data will be transferred in the background. The staging workspace will then hold these commands, data, and version information until a Submit command is issued from your local workspace. Then your staging workspace, like a faithful servant, will relay all things it’s holding on your behalf to the branch it belongs to.

So what exactly happens when you work in offline mode? It is quite simple actually. A flag is set to tell the system that it should stop communicating with server, the corresponding staging workspace to be precise. And a select few options and commands will be disabled. That’s it. Aside from the changes just mentioned, Firefly Client will function and run like normal.

What exactly is disabled?

The most important and perhaps noticeable difference between online and offline mode is that you will no longer have access to data other than those sitting on your hard disk. This may sound like pointing out the obvious but it has some subtle impacts.

From the main form of the client GUI, you will no long be able to see other people’s changesets and their contents.

You will no longer be able to drag files or changes from one changeset to another. Once a file settles in a changeset, it will stay there in offline mode.

The version tree will still work but will only display versions on your hard disk.

You will only be able to see local versions in History

And obviously, you won't be to able to perform Bringover or Submit

Otherwise, you can go about your daily work as usual and hardly notice that you are working in offline mode, with no connection to the server at all.

Things to bear in mind when working in offline mode

You will notice there are two network statuses: online/offline and connected/not connected.

Aren’t they repetitive? Actually, no. The "online/offline" status indicates which mode you are working in. In other words, it indicates if the client software attempts to communication with the server. The "connected/not connected" status, on the other hand, indicates if you are currently connected to the server. Firefly Client attempts to connect to the server in online mode upon start up. An established connection will drop after 15 minutes of idling (no data exchange). When working in offline mode, the second status will always be disconnected.

If you did a fair amount of work in offline, you will probably experience a temporary hang in Firefly Client when switching back to online mode. This is due to the data exchange between the client and the server. The client will go back to normal after a period of time (depends on how much data is waiting to be transferred. Normally, it is just a few seconds). So don’t panic.

Offline status is workspace specific, meaning if you set one workspace to work in offline mode, it will not affect other workspaces on your computer.

What DO you get in offline mode?

Pretty much everything. You can go about your development work as usual. You can add files to source control, drag one (or more) to a changeset (checkout), edit, save, edit again, decide to roll back to the version you just saved, rename, move it/them to some other directory, delete, undelete, display a visual version tree, etc.

Here are the finer points on Firefly offline development support:

Hassle free
You don’t have to mirror a local repository, and then make a local copy of the mirror for development purposes just so you can get started. There’s no complex script to write, no excessive commands to be executed. Turn on the offline option and you are ready to go.

Save multiple versions on the road
In Firefly, you can save as many versions of a file as you want while working in offline mode the whole time. You can edit, save a version (using the Delta command), edit, save a version again. You can then use the List Pending Changes command to review all saved versions. All history will be recorded and merged back to the branch when you get back online.

Move and Rename support
Firefly supports move and rename in offline mode, effortlessly. There are no specially steps to take in order to preserve Move/Rename operations in history. One of the problems with other version control tools is that if you rename multiple files, the system gets confused. For an example, if you rename a.c to b.c and c.c to d.c while in offline (disconnected) development, the system has no way of knowing if b.c came from a.c or c.c. Some of them might know there are two files renamed, but they can’t put their fingers on which file was renamed from which.

Intelligent Delete operation
Unlike most version control tool, Firefly is able to distinguish between missing file and deleted files in offline mode. Firefly delete is recorded by the system as part of the history. The content and history of the deleted file is preserved in case it's needed later. This also makes Undelete support possible.

Undelete support
To undelete a file while working in offline mode is exactly the same as undeleting a file in normal mode. There’s no need to blindly revert the file back to a previous version then add them back to the branch.

Changeset creation
Firefly supports offline changeset creation. This means you can take task-oriented opeation with you on the road.

A real world scenario

Let's look at an example on how best to implement offline development with Firefly.

Tom has been working on Nvi 1.8.1 bugfix in his office on his desktop. Now he has to take an airplane to the west coast to provide some onsite technical assistant to one of the clients. Why let the six hours on the plane go wasted he thinks. Better get some of these bugs fixed. So what he does is,

he sets up a local workspace on his laptop, under the same branch, and bringover all the necessary code.

he sets his workspace on the laptop to work in offline mode. Now he is all set to go.

Tom hacks away on the plane and really got some work done because there's really nothing better to do 40000 miles up in the air.

Tom comes back into the office, connects his laptop, set it to work in normal mode, submits all changes he made.

Then he turns on his desktop and do a Bringover.

DONE!