söndag 20 september 2009

Why Google Chrome?

Why are Google creating yet another web reader? There are already a couple of them in the market. Is it to get control over the end users? Some fear that Google will use it to be able to sell even more advertising.

I don't think that is the primary reason. Indirectly, yes, but not in a direct way. Google wants people to use the web more, and it certainly looks like it will be very big in the future. There are two interesting features with Google Chrome: Improved navigation and improved Java Script execution.

Improved navigation (using the Omnibox as well as the new tab page), will make it easier for users to find what they want and have them stay longer, browsing the world.

It is not obvious why Google spend a lot of effort on improved Javascript execution speed. However, when you consider O3D, you get a hint what it is all about. O3D is a plugin that supports 3D graphics using the hardware acceleration of the graphic cards. This plugin use Javascript for execution, and if it will become a success, it is not acceptable with slow applications. The hope is that there will be more 3D games available online, where you don't have to install anything. You simply execute them on the web. If these games only work good enough on Google Chrome, guess what is going to happen? All other web browse suppliers will have to improve the Javascript engine execution. That way, Google wins even if people use other web browsers. That is, people stay more on the internet.

And then, Google Chrome pushes html 5, which will even further improve web browsing.

Using Subversion in big projects

Using Subversion in big projects

Requirements on the Subversion setup

  1. It shall support an integration phase, where selected sub components are merged into one result.
  2. The sub components shall be possible to develop independently on the main application.
  3. The merged result shall be saved henceforth.
  4. It shall be possible to take a selected merged result and afterwards find out what it was integrated from; what the versions of the sub components are.
  5. All users of the application shall automatically get the same versions of the cub components, without having to do anything.

Suggested folder structure

This example project consists of one or more applications, where each one uses the sub components in Modules. Notice that the sub components in Module each have the usual branchestags and trunk folders. The idea is that a release of a sub component is defined using a tag, or R1 in this example. Main projects should only refer to to the tags R1, etc, not to the trunk of a sub component.


If this project would have been check out from the BigProject level, each application would be able to refer to the sub components in the Modules using relative paths. However, the reference would depend on the tag names (R1, etc). Every time we would want to use a new release of a sub component, the source code in the main application would have to be changed so as to refer to the new tag.


Instead, a checkout of Application1 shall be done from trunk. Let's say it is called Application1. This folder will then have the property "svn:externals" added. This external definition will add one or more sub components from the Modules folder as a sub folder to the checked out project (Application1). The folder structure will thus look as follows. Notice that Core and Module1 look like they are part of the Application1 project.

The externals definition used for this are as follows. The peg revision was 28 in this example, but that of course depends on what version the sub components were released.
^/BigProject/Core/tags/R1@28 Core
^/BigProject/Module1/tags/R1@28 Module1
Notes
  • Always use version number reference for externals, using peg revision format. That is, suffix the source path with "@" and the revision number. Otherwise, if a module is renamed or moved elsewhere, it can no longer be referenced. This is needed even if it is a reference to a tags item.
  • The externals can be in the same repository or another one. If it is in the same repository, use the relative repository path address "^/Module1/tags/R1" for example.

Comments are welcome!

Lars Pensjö 2009-09-20