VISTAS Internals

Developers’ Documentation

VISTAS is implemented in C++.  See an Overview of VISTAS Architecture.  VISTAS code is available on Mecurial at the VISTAS Bitbucket repository.    The top level link for the source code repository is https://bitbucket.org/nikmolnar/vistas/.

To explore the source code, you can click ‘Source’ in the lefthand side panel, or you can add ‘src’ to the top level link (i.e. https://bitbucket.org/nikmolnar/vistas/src). If you want the source code, you can either clone the Mercurial project, or download one of the branches (most likely the ‘master’ or ‘develop’ branch) as a zipped archive (see https://bitbucket.org/nikmolnar/vistas/downloads/?tab=branches).

Some important points:

  1. VISTAS team members need to create a Bitbucket account and send us their usernames for write permissions to the repository.
  2. For interacting with the repository, we recommends TortoiseHg on Windows (you’ll often see Mercurial referred to as Hg, its short name–the element code for mercury) or SourceTree on Mac.
  3. For those used to Google subversion, the transition should be fairly easy, but there are some important differences. First, take a look at the Mercurial quickstart:  http://mercurial.selenic.com/quickstart/.  Note: a) commit and push are separate operations, as are pull and update. Thus, when you pull commits from the central repository, Hg won’t update your codebase on disk until you “Update” to the latest revision.   b) merging is a common operation. For example, let’s say you commit some code, creating a changeset, and then pull down a changeset from the central repository. This will result in two heads for that branch; you’ll need to merge them, which creates a third changeset, bringing the divergent paths together. This is a common operation, and once you do it a few times it will become second nature.
  4. Switching branches is super easy. First, make sure all your uncommitted changes are committed or shelved, then (in TortoiseHg) right-click on the latest changeset in the branch you want to work on and choose “Update”.
  5. Please use the branching model described in this article: http://nvie.com/posts/a-successful-git-branching-model/. The upshot: development happens on the “develop” branch (for short, self-contined updates only), or on “feature” branches, which when finished are merged into develop. “Release” branches are created from the develop branch, which are them merged into the “master” (or in our case “default”) branch which is where production-ready builds are created from. Any bugs which need to be fixed before the next planned release can be represented as “hotfix” branches, which stem from the default (production) branch, and then merge back into default (for an updated production-ready build) and into develop. The graph at the top of the article does the best job of explaining this. There is an extension to hg, called hg flow which facilitates all these operations; all the installation and usage info here: https://bitbucket.org/yinwm/hgflow/wiki/UserManual
  6. Many small commits are best: try for single-topic commits where the commit message fully represents the changes. This is especially easy when developing on a “feature” branch, as you don’t need to worry about breaking the everyone else’s build before your feature is complete.
  7. We are currently migrating the wiki pages. Please go through the issues list on Google Code: copy the issues you want to keep to Bitbucket, and then delete your issues from Google Code.

In case you are wondering:  gd-2.0.34-win32.zip on the download page is a dependency to build VISTAS.

The Evergreen VISTAS fileshare and the developers’ Issue & Task Tracker for the project (basically a Kanban board)  are available only to project team members.