From Kokua Wiki
Jump to: navigation, search

This page contains links and information related to Kokua Viewer development. For Imprudence Viewer development, see Imprudence:Development.


Compiling Kokua

Using autobuild to compile

Building with autobuild (short outline)

Kokua Developer Workflow DRAFT

A Working Environment

Mercurial Queues (MQ) and Bitbucket (Bb) Workflow DRAFT

Adding a queue to a bitbucket mercurial repo

  • Start with a Bitbucket (Bb) repository. Either new or fork an existing one.
  • From the Overview tab, select patch queue and in most cases check omit series.
  • You may want to make this a Private repository as it will hold your work in progress.
  • Similar to forking, Bb will work to make your queue.

Cloning a queue to your local system

  • When Bb finishes the queue, work shifts to your local system.
  • hg qclone the just completed queue.
  • This is a clone of you main repository and a structured empty MQ repository.
  • The main repository is in its named directory and is now your work repository.
  • The MQ repository exists in .hg/patches and it has an .hg directory for MQ commits.
  • The directory .hg/patches holds named patches and a couple housekeeping files.
  • Edits to .hg/hgrc and .hg/patches/.hg/hgrc files may be needed to customize the workflow.
  • I think it may be a Bb bug, but after hg qclone, .hg/hgrc has a default location of the queue versus the main and is not where you should hg push and hg pull from. In the test environment, I used a pristine local repository for the default location and the Bb main repository for default-push. The MQ repository .hg/patches/.hg/hgrc has a default of the Bb queue, so no edits are required for it.

Interacting with the local queue

  • hg qnew my-really-cool-patch. This places an empty named patch in .hg/patches.
  • work on and edit your sources
  • hg qrefresh To update my-really-cool-patch file that is in .hg/patches.
  • work on and edit your sources some more
  • hg qrefresh To update my-really-cool-patch file that is in .hg/patches again.
  • hg qpop removes the working tree changes. Similar to hg refresh --all. But, the working tree can be set back to its last patched state with hg qpush. Or, you can reorder things by named patches otherwise you work from top of the working tree stack and the MQ stack. Commands hg qpop and hg qpush are in reference to the working tree stack.
  • If your patch is valuable and may be of use again, you can commit it and push it to the queue on Bb. hg qpop it off the working tree stack, hg commit --mq -m"stuff" it is now revision control hg tip --mq to view details and hg push --mq puts in the Bb queue repository.

Pushing changes to the remote queue or remote repository on bitbucket

  • Now to close the loop. We hg qpush onto the working tree and tested and all is as we desire. hg qfinish takes the patch and makes a main repository commit and removes it as as named patch from .hg/patches.
  • hg tip displays data about the new tip and then hg push sends it along to the Bb main repository.
  • Now generate a pull request for upstream for my-really-cool-patch.


Communication Channels

These are the most relevant communication channels for viewer development:

Technical Documentation