NetBeans, Qt and Git   Leave a comment


An important aspect of software development is “source control”, enabling the tracking of changes, bug fixes and releases. I used Subversion for this purpose. There are several other source control systems available, one of which is Git which appears to me to be on the rise in popularity. I develop my software using NetBeans IDE (currently version 8.0) which integrates well with Subversion, two other source control systems are also supported by NetBeans: Mercurial and Git. The best way to get a feel of NetBeans and Git is to try it out.

Subversion is organised such that a single repository can contain many projects, Git usually has a repository for each project. To try out Git, projects in the Subversion repository have to be converted into Git repositories. For this post I’m using TitanQt as an example. Here’s its structure shown in a RapidSVN window:

TitanQt in Subversion

TitanQt in Subversion

The structure of TitanQt is common to many Subversion projects, there’s the main development trunk, two version branches and three tagged releases. Ideally the tagged versions should be a snapshot of the code, however, in Subversion they are code branches and there is nothing to stop revisions being applied to them.

I’m not going to show the steps involved in converting a Subversion project into a Git repository, I followed the instructions detailed here missing out step 3. One thing not mentioned in the steps to convert a Subversion repository is that extra branches and tags may appear, they have the form of an existing name qualified by an @ symbol followed by a revision number. Any extra branches and tags can be safely deleted.

A Git repository is usually embedded within a working directory. Git repositories shared between users are shorn of their working directories, such remote or “bare” repositories can be stored anywhere, usually on a server, in my case, development is on one computer and the repository only has one user. I keep bare Git repositories in a separate directory to project development and there are off site backups in the “cloud”.

To open a NetBeans project from a remote Git repository it needs to be cloned:

Cloning a repository step 1

Cloning a repository step 1


Cloning a repository step 2

Cloning a repository step 2


Cloning a repository step 3

Cloning a repository step 3

IMPORTANT: select all the remote branches, if you don’t only the branches selected will be available to the cloned repository.

Cloning a repository step 4

Cloning a repository step 4

TitanQt is a NetBeans Qt project, many files are automatically generated. When I first put TitanQt under source control I was unaware of the extent of the auto generated files and as a consequence several of them are in the Git repository. The contents of the nbprojects directory can be stripped back to just two files: configurations.xml and project.xml. Once these files have been deleted the changes are committed. There are two ways in NetBeans of listing the changes to be committed via the Team menu or by using the popup menu when right clicking on the project name in the Project or File tabs.

Show changes via Team menu

Show changes via Team menu

Show changes via popup menu

Show changes via popup menu

The list of file changes to be committed:

List of files affected

List of files affected

Commit the changes

Commit the changes

Qt implements many of its features by the use of a C++ preprocessor thus Qt classes generate file of the form moc_*.cpp, Qt resource file also generate files of the form qrc_*.cpp. By default these files are generated in the same directories as the project’s source files, they can be kept separate by setting project properties:

Project properties

Project properties

Qt properties

Qt properties

Specifying MOC and RCC directories keep the auto generated files away from the project source files.

Building the project and showing the changes reveals a list of changes including auto generated files. The auto generated files are just clutter and should be ignored.

Changes after build

Changes after build

In the picture above the build and dist directories are grey and NetBeans ignores these directories for source control purposes. There is a discrepancy between NetBeans and the git status command at the command line:

git status

git status

The dist directory is mysteriously missing from git status, but the directories for build, moc and qrc are present along with .dep.inc, NetBeans, however lists every file in directories moc and qrc and .dep.inc isn’t mentioned at all.

Directories and file can be ignored using NetBeans via the pop up menu or the Team menu.

Ignoring a directory

Ignoring a directory

As soon as something is ignored a .gitignore file is created. To get the build directory to disappear from git status the .gitignore file has to have “/build/” added to it using the editor as NetBeans doesn’t allow build to be ignored or unignored. The .gitignore file is used by Git to ignore files and directories and is very flexible, a pattern such as “nbproject/*.mk” can be added which indicates that all files that match that pattern should be ignored, NetBeans does not provide a means for adding such patterns from the menus but, of course, the file can be edited. Adding the appropriate patterns results in git status reporting that only the .gitignore file is being tracked. NetBeans doesn’t take account of patterns it only handles files and directories, some files and directories are grey and they can’t be added to .gitignore via the menus. In order to get git status and NetBeans to agree with each other the .gitignore file must be edited and it must not include patterns.

The .gitignore file

The .gitignore file

Now the .gitignore file can be committed. The local and remote repositories now differ, the local changes are applied to the remote repository using “push”.

Push

Push

That’s tidied up the project files for master (trunk in Subversion). Branches version-4.0 and version-4.1 have to tidied up in the same way. But what of the tags? To show that the Git repository matches up with the Subversion project the repository browser can be started from either the Team menu or from the pop up menu.

Repository browser

Repository browser

All the branches have been expanded showing master, two version branches and three tagged releases. Note that branches only exist at this stage on the remote repository, to start work on a branch a copy needs to transferred to the local copy using checkout. Checkout is available from both the the Team menu and the pop up menu.

Checkout step 1

Checkout step 1

Checkout step 2

Checkout step 2

At this stage a commit revision id, branch name or tag name can be entered or the select button used.

Checkout step 3

Checkout step 3

Once the revision has been selected the “Checkout Selected Revision” dialogue reappears.

Checkout step 4

Checkout step 4

Note the check box for creating a local branch, when a local branch is created it corresponds to the remote branch which allows changes made locally to pushed to the remote repository.

Git tags correspond to a snapshot of the code when it was tagged, in the case of tagged release code no changes should be allowed. To achieve this the create branch check box should remain unchecked.

Checking out a tag

Checking out a tag

Any changes to a tag can not be pushed to a remote. Sometimes changes have to made to get a program to build for example the names of boost libraries can change, on Linux Mint 15 the boost library names used ended in -mt on Linux Mint 17 none of the boost library names end in -mt and the boost system library is now required. It isn’t necessary to commit such changes but they can be added to the repository by creating a new branch applying changes to that and creating a new tag.

So that’s it, TitanQt is now in a Git repository, NetBeans integrates well with Git with the exception of .gitignore and changes have to pushed to the remote repository unlike Subversion where the repository is in effect always remote.

Update

Since I wrote this post I’ve become aware of some aspects of using NetBeans that I missed.

  • Push should be applied to each branch.
  • Patterns can be used in a .gitignore file but NetBeans only recognises them once the .gitignore file has been checked in.
  • When checking out a branch it is only necessary to check the create branch box if the branch doesn’t already exist in the local repository.
  • NetBeans displays a dialogue (see below) when a local branch is created when checking out a revision.

The following dialogue is displayed when a new local branch is created when checking out a revision even though git status from the command line reports no local modifications.

Unexpected dialogue

Unexpected dialogue

Select review. The new local branch is created but NetBeans refuses to switch branches, reverting to the command line the checkout completes without a murmur and NetBeans switches to the new branch.

Advertisements

Posted 7 July 2014 by element90 in Development

Tagged with , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: