Introduce support for location views

[Nick Clifton]

Hi Alex,

> Another issue I wanted to discuss is whether there's any interest in
> retaining development history of this patches.  I've been working on it
> in a branch, users/aoliva/SFN, and I was thinking it might make sense
> for the patch that eventually gets committed to the master branch to be
> a merge from the branch, that adds the consolidated ChangeLog entries,
> rather than a single stand-alone commit that drops the development
> history.
> 
> My reasoning is that, although we have comments and ChangeLogs and
> commit messages and email archives and whatnot, some of the development
> history behind certain changes will certainly be in the development
> commits only, and if we don't bring those into our commit history, they
> will likely be lost forever.
> 
> I can see the benefit of them when bisecting patches for the kernel
> linux, for example, since a GIT pull request will bring some (possibly
> revised/consolidated/rewritten/polished/cleaned-up, but still...)
> development history that might shed light on issues that arise later.
> 
> We currently throw that on the floor, but there's no reason for us to do
> so.  Since we use GIT for the revision history, it would be trivial to
> install the consolidated patch as a merge that pulls in the development
> history from the branch, along with the intended changes, if we choose
> to do so.
> 
> Just to be clear, what I'm suggesting is that, when development history
> for a patch is available, its commit be a pull/merge, so that the
> development history becomes part of the project history even if the branch
> was never published or was but gets removed later.  It would in no way
> affect the checked-out tree, so the patch would add the same bits,
> including ChangeLogs and whatnot, and would carry the same commit
> messages that a regular commit would.
> 
> Thoughts?

I like it.  I am all in favour of providing future users/coders with as
much (useful) information as is possible.  

Cheers
  Nick