Storing different content in a Git branch

If you are used to the Subversion way of doing things, branches tend to have more or less the same content/code, obviously with a few changes as the development progresses.

But in Git one can store content that is completely different from the content in a branch.

Now you might wonder why one would want to do that. But I guess there are some reasons for it. For example, I believe the Git repository itself has a TODO branch that allows developers to keep notes on what needs to be done in the future, but does not contain code. That way notes are versioned as well.

The thing about Git is that it allows for easy setup of such not-ordinary uses of a version control system — I think that is what gives it “more legs” over other DVCSs. And why one should look at using Git over other DVCS systems.

Have a look at this screencast that takes one through how to create such branches — also referred to as “empty branches” because one creates an empty branch, and then fills it with other content that does not relate to the master branch.

But if you want to create a branch like that, you can use the following code that I found buried in one of the comments on the screencast.

git symbolic-ref HEAD refs/heads/newbranch
rm .git/index
git clean -fdx
<<<< do your work >>>>
git add your files
git commit -m 'Initial commit'

Just gotta love Git.

Using Decentralized Version Control with CF – My talk at CFObjective ANZ

A couple of weeks back I presented at CFObjective ANZ in Melbourne, on how to make ColdFusion development a little more cooler using a decentralized version control system (DVCS) like Git.

The basic idea behind the presentation was this:

A commonly used version control system in the ColdFusion community is Subversion — a centralized system that relies on being connected to a central server. The next generation version control systems are decentralized, in that version control tasks do not rely on a central server.

Decentralized version control systems are more efficient and offer a more practical way of software development.

In this session, I covered considerations in moving from Subversion to Git, a decentralized version control system. And also the pros and cons of each.

Version control is often used in conjunction with a testing framework and continuous integration. I wanted to demo an example of how to integrate Git with a testing framework, MXUnit, and a continuous integration server, Hudson. But ran out of time. So maybe that is something I can do another time in another conference!

You can download a PDF it here: Make it Cooler – Using Decentralized Version Control

Or view it at SlideShare.

Would like to hear from you on what you think of it.

Apache Rewrites for Subfolder Install of CFWheels

By default the CFWheels framework and application is installed in the webroot.

But if you want to install it in a subfolder in the webroot, you need to change the rewrites slightly.

I use the following and it works quite well.

In the example below, I have a server called hello.cfwheels.local, and it points to a folder under the webroot called hello.

ServerName hello.cfwheels.local

RewriteEngine On
RewriteOptions Inherit

RewriteCond %{REQUEST_URI} ^.*/(flashservices|flex2gateway|railo-context|robots.txt)($|/.*$) [NC]
RewriteRule ^(.*)$ http://127.0.0.1:8080/$1 [P,L]

RewriteCond %{REQUEST_URI} ^.*/(files|images|javascripts|miscellaneous|stylesheets|plugins|sitemap.xml|rewrite.cfm)($|/.*$) [NC]
RewriteRule ^(.*)$ http://127.0.0.1:8080/hello$1 [P,L]

RewriteRule ^(.*)$ http://127.0.0.1:8080/hello/rewrite.cfm$1 [P,L]

RewriteRule ^/(.*)$ http://127.0.0.1:8080/hello/rewrite.cfm/$1 [P,L]
ProxyPassReverse / http://127.0.0.1:8080/hello/rewrite.cfm/

ProxyPreserveHost on

If you think there is a better way to accomplish this, please drop in a line.

Search CFWheels Documentation

CFWheels has excellent documentation. Well organized, sufficiently detailed, well presented.

Something that is missing at the moment, and is on the list of things to-do for the CFWheels team, is to add a search feature to the docs.

Till the time that feature is implemented, I created a Google custom search for CFWheels docs.

I just find that after one has understood the basics and has started building an application, there is a need to be able to quickly search for information rather than go through listing of topics to figure out where can one find a piece of information.

To that end, a search interface proves very useful.

So, if you want to search CFWheels documentation till the time a formal search is put on the site, you are more than welcome to use the custom search that I use.

You can access the search at: http://blog.nagpals.com/utils/cfwheels/search/

Or use the search box below to search:

Loading

Life after Subversion — Mercurial!

A note to myself: The only constant in life, Indy, is change!

I’ve been using Subversion for version control for a couple of years now. It was quite a change moving from Microsoft Visual Source to Subversion. A different mind set. A different way of doing things.

And then I read about Mercurial today.

Mercurial is one of the new breed of version control systems.

Its major goals include high performance and scalability; serverless, fully distributed collaborative development; robust handling of both plain text and binary files; and advanced branching and merging capabilities, while remaining conceptually simple. It includes an integrated web interface. (Wikipedia)

Basically Mercurial moves away from the paradigm of working with centralized repositories (like CVS and SVN) to support distributed, collaborative development. And at the same time trying to be a simple-to-use system (a big challenge!).

There is a great little article on JavaWorld comparing different version control systems. It is quite enlightening: Subversion or CVS, Bazaar or Mercurial?

The article explains in simple words what Mercurial is on page 4.

Mercurial is newer open source version control system based on the distributed model. In Mercurial, as in Subversion or CVS, developers work on a local working directory. However, unlike centralized solutions, Mercurial also stores a copy of the entire project history on each developer’s machine. In this way, developers can work in parallel, even without a network connection.

…

Unlike Subversion, however, when you commit changes in Mercurial, you only create a new revision in your local repository (which, given Mercurial is based a distributed model, is considered to be just as good a repository as anyone else’s).�

Seems like an intriguing concept. I’ve been going through the documentation on Mercurial site and it seems to be very well documented.

In terms of companies/projects actually using Mercurial, Sun Microsystems software (including Open Solaris and NetBeans) and Mozilla are using it to manage open-source initiatives. These are project where the need for distributed collaborative version control is quite high.

Well… it’s time to give it a try!