Wednesday, July 30, 2008

Common Branching Patterns

Version control is most often used for software development, so here's a quick peek at two of the most common branching/merging patterns used by teams of programmers. If you're not using Subversion for software development, feel free to skip this section. If you're a software developer using version control for the first time, pay close attention, as these patterns are often considered best practices by experienced folk. These processes aren't specific to Subversion; they're applicable to any version control system. Still, it may help to see them described in Subversion terms.

Release Branches

Most software has a typical lifecycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality-assurance teams take time to test supposedly-stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bugfix without having to wait for a major new release.

Here's where version control can help. The typical procedure looks like this:

  • Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bugfixes, and so on.

  • The trunk is copied to a "release" branch. When the team thinks the software is ready for release (say, a 1.0 release), then /trunk might be copied to /branches/1.0.

  • Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is "frozen" for final testing right before a release.

  • The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.

  • The branch is maintained over time. While work continues on /trunk for version 2.0, bugfixes continue to be ported from /trunk to /branches/1.0. When enough bugfixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.

This entire process repeats as the software matures: when the 2.0 work is complete, a new 2.0 release branch is created, tested, tagged, and eventually released. After some years, the repository ends up with a number of release branches in "maintenance" mode, and a number of tags representing final shipped versions.

Feature Branches

A feature branch is the sort of branch that's been the dominant example in this chapter, the one you've been working on while Sally continues to work on /trunk. It's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, then ultimately deleted. They have a finite span of usefulness.

Again, project policies vary widely concerning exactly when it's appropriate to create a feature branch. Some projects never use feature branches at all: commits to /trunk are a free-for-all. The advantage to this system is that it's simple—nobody needs to learn about branching or merging. The disadvantage is that the trunk code is often unstable or unusable. Other projects use branches to an extreme: no change is ever committed to the trunk directly. Even the most trivial changes are created on a short-lived branch, carefully reviewed and merged to the trunk. Then the branch is deleted. This system guarantees an exceptionally stable and usable trunk at all times, but at the cost of tremendous process overhead.

Most projects take a middle-of-the-road approach. They commonly insist that /trunk compile and pass regression tests at all times. A feature branch is only required when a change requires a large number of destabilizing commits. A good rule of thumb is to ask this question: if the developer worked for days in isolation and then committed the large change all at once (so that /trunk were never destabilized), would it be too large a change to review? If the answer to that question is "yes", then the change should be developed on a feature branch. As the developer commits incremental changes to the branch, they can be easily reviewed by peers.

Finally, there's the issue of how to best keep a feature branch in "sync" with the trunk as work progresses. As we mentioned earlier, there's a great risk to working on a branch for weeks or months; trunk changes may continue to pour in, to the point where the two lines of development differ so greatly that it may become a nightmare trying to merge the branch back to the trunk.

This situation is best avoided by regularly merging trunk changes to the branch. Make up a policy: once a week, merge the last week's worth of trunk changes to the branch. Take care when doing this; the merging needs to be hand-tracked to avoid the problem of repeated merges . You'll need to write careful log messages detailing exactly which revision ranges have been been merged already. It may sound intimidating, but it's actually pretty easy to do.

At some point, you'll be ready to merge the "synchronized" feature branch back to the trunk. To do this, begin by doing a final merge of the latest trunk changes to the branch. When that's done, the latest versions of branch and trunk will be absolutely identical except for your branch changes. So in this special case, you would merge by comparing the branch with the trunk:

more details :

-- regards,

chamath gunasekara,

Sunday, July 27, 2008

Unix File Systems

1) "/bin" - contains essential system commands and programs (in machine-readable format, or "binary" format, which is what "bin" stands for),
such as "ls," "cp" (used to copy files), "mv" (used to move files to a different location), and so on. It also contains "bash," which is most likely the shell you are currently using. The shell is a program that allows you to issue commands to the operating system and view their output. When you are working in a terminal window, you are using the shell.

2) "/boot" - contains files necessary for booting the system. If you're not familiar with this term, it describes the process of starting the system when it is powered on or restarted. During this process, a number of things happen. These might include checking the integrity of your disks, detecting hardware and getting it ready for use by the system, and starting essential programs that help to keep the system running. Also, the kernel (the "guts" of your system) may be stored in "/boot".

3) "/dev" - contains files which represent system devices, such as your hard disks, serial ports, mouse, etc. For example, "/dev/hda" represents the first IDE device on your system, usually your hard drive. If this sounds confusing, don't worry -- understanding what is in this directory is the most important part.

4) "/etc" - contains essential system-wide configuration files. When administering your system, you'll frequently be editing files in this directory. They control many system services and settings. Some examples of files in this directory are "/etc/resolv.conf" (contains your nameserver information) and "/etc/fstab" (a table of devices or directories that hold data and need to be accessed by the system, such as your hard drive or a CD-ROM drive). Program-specific configuration files may be here as well, and are usually identified by the letters "rc" at the end of the filename, for "run commands." An example of this might be "/etc/vimrc" (a system-wide configuration file for the vim text editor).

5) "/home" - contains the home directories for all regular users. A home directory is where a user generally stores personal files. For example, if your username is "tom," then your home directory is "/home/tom." A convenient shortcut for referring to your home directory is "~/" (a tilde, followed by a forward slash). So, for the user "tom," "~/mp3/moby.mp3" actually refers to the file "/home/tom/mp3/moby.mp3".

6) "/lib" - contains system libraries. Libraries are files that contain program code that is common to several applications. For example, a common thing that a program might need to do is write out to a file somewhere on disk. Rather than have to include that code in every program they write, programmers can simply point to a specific library which contains that functionality. Libraries help to keep programs smaller, more efficient, and easier to maintain. Another thing you'll find in this directory, under "/lib/modules/(kernel-version)" are your kernel modules. Modules usually serve as device drivers -- that is, they provide the necessary interface for "talking" to your system hardware, such as a network card or a SCSI CD-ROM drive.

7) "/mnt" - contains "mount points," which are the locations you would use to access files on various different media such as floppies or CD-ROMs. For example, "/mnt/floppy" would be where you would usually access your floppy. All this is defined by the "/etc/fstab" file mentioned above.

8) "/proc" - contains files with system information. For example, "/proc/cpuinfo" has information about your computer's processor, and "/proc/modules" lists which kernel modules are currently loaded in the system.

9) "/root" - contains the "root" user's home directory.

10) "/sbin" - contains commands used by the superuser ("root") for system administration. These include commands such as "shutdown" (used to shutdown or reboot the system) and fsck (a tool for checking and repairing the data on your hard disk, similar to "scandisk" on Windows).

11) "/tmp" - a place to put temporary files. Applications use this directory often, which can be accessed by all users on the system.

12) "/usr" - contains a number of important subdirectories. "/usr/bin" contains the bulk of the programs on your system. "/usr/sbin" contains important commands for system administration that are not already in "/sbin." So, why the difference between "/bin" and "/usr/bin", or "/sbin" and "/usr/sbin"? Well, "/bin" and "/sbin" should contain all the commands necessary for getting the system up and running, without being connected to the network. This allows "/usr" to actually be located on another computer on the network, and remotely accessed. Now, let's take a look at the rest of the "/usr" subdirectories. "/usr/lib" contains more system libraries, (as discussed above). "/usr/include" contains additional common pieces of code, similar to libraries, but used when compiling software. Compiling software is the process of taking "source code" (the human-readable instructions written by programmers using a programming language, such as C), and using a special program called a "compiler" to create a file that can be understood by the computer, called a binary file. "/usr/src" contains source code stored on the system (such as the Linux kernel source, or source code that you may have downloaded so that you can compile a program by hand). Finally, "/usr/local" contains programs and data files that have been added locally to the system, and are intended to be kept separate from the main system directories.

13) "/var" - contains administrative files (such as system logs), and data that changes frequently (such as incoming mail and news).

Wednesday, March 19, 2008

Linux Script for start and stop a specific process

This is script which I wrote to start and stop java program in rebhat linux. I think it should be run in any linux environment. I did not check that in other destro.

Start Script -

nohup nice java -cp ./:lib/mysql.jar:lib/activation.jar:lib/imap.jar:lib/mailapi.jar:lib/pop3.jar:lib/smtp.jar:./:bin KappaUserChecker > ./kappauc.out 2>&1 &

Stop Script -

kill `ps -ef | grep KappaUserChecker | grep -v grep | awk '{ print $2 }'`


nohup nice

nohup is a Unix command that is used to run another command while suppressing the action of the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. It is most often used to run commands in background as daemons. Output that would normally go to the terminal goes to a file called nohup.out if it has not already been redirected.Nice allows you to run a program with a modified scheduling priority with -20 being most important and 20 being less important. I believe the default when using nice without a value is 0.

The '>' command

Takes the output from my java command and places it in the file ./kappauc.out

The '2>&1' command

2> is standard error and &1 is standard output. So combined it says take standard error and put it in standard output, which the previous command said take standard output and put it in
./kappauc.out. So together these two commands put standard output and error in ./kappauc.out.

The '&' command

When appending it at the end like it is, it means runs this process in the background.

Stop Script explained

Uses the Process Status (ps) command and grep to search for a process that includes the text 'hudson-1.136.war'. Then it uses awk to split out the output from ps to get the Process ID. Once the Process ID is found it passes it to the kill program to stop the daemon (pipes rock!). This method of using kill to stop a process is rather brute force and does have some flaws if you don't use unique text to search (multiple users running hundreds of programs). Most programs, say weblogic, for example should already have a stop script, so obviously prefer those over my example.

So what if you want the startup script to begin at boot time? Well, add a soft link pointing to your startup script  (ln -s /home/YourProject/bin/ in /etc/init.d/. Then use the update-rc.d command to add it at boot time (update-rc.d softlink_name defaults).

chamath gunasekara,

Wednesday, March 5, 2008

The Arabidopsis Information Resource (TAIR)

The Arabidopsis Information Resource (TAIR) maintains a database of genetic and molecular biology data for the model higher plant Arabidopsis thaliana. Data available from TAIR includes the complete genome sequence along with gene structure, gene product information, metabolism, gene expression, DNA and seed stocks, genome maps, genetic and physical markers, publications, and information about the Arabidopsis research community. Gene product function data is updated every two weeks from the latest published research literature and community data submissions. Gene structures are updated 1-2 times per year using computational and manual methods as well as community submissions of new and updated genes. TAIR also provides extensive linkouts from our data pages to other Arabidopsis resources.

chamath gunasekara,

Monday, October 29, 2007

What is HSDPA?

HSDPA, short for High-Speed Downlink Packet Access, is a new protocol for mobile telephone data transmission. It is known as a 3.5G (G stands for generation) technology. Essentially, the standard will provide download speeds on a mobile phone equivalent to an ADSL (Asymmetric Digital Subscriber Line) line in a home, removing any limitations placed on the use of your phone by a slow connection. It is an evolution and improvement on W-CDMA, or Wideband Code Division Multiple Access, a 3G protocol. HSDPA improves the data transfer rate by a factor of at least five over W-CDMA. HSDPA can achieve theoretical data transmission speeds of 8-10 Mbps (megabits per second). Though any data can be transmitted, applications with high data demands such as video and streaming music are the focus of HSDPA.

See also

What is badware?

There are several commonly recognized terms for specific kinds of badware - spyware, malware, and deceptive adware. Badware is malicious software that tracks your moves online and feeds that information back to shady marketing groups so that they can ambush you with targeted ads. If your every move online is checked by a pop-up ad, it's highly likely that you, like 59 million Americans, have spyware or other malicious badware on your computer.

What's particularly tricky about badware is that you may not know that you downloaded it. Some badware manufacturers bundle it with other programs without disclosing that it's part of the package. Others put their programs on your PC when you visit certain websites or play online games.

Unfortunately, incessant pop-up ads aren't the only possible side-effect. Sometimes peoples' computers slow down or even crash. Sometimes peoples' personal information is abused, and there have been reported cases of identity theft. What's even more frustrating is that these programs are hidden in your computer, making it difficult to identify and remove them.

Why do badware providers make the effort? Because it is big business, amounting to a $2 billion-a-year industry. It's the Wild West of aggressive marketing and an industry supported by shadowy online marketers, small application vendors, and website operators.

The best and most important thing is for you to learn how to clean badware off your computer and to share your knowledge with those you know. An important factor when installing any software application is whether you have agreed to its installation and understand what it will do. Certain types of badware not only adversely affect your browsing experience, but how your computer itself functions. Some badware is known to interrupt your internet connection or even cause your computer to crash.

go to this site, to get more about badware -

Friday, July 27, 2007


DjVu (pronounced déjà vu) is a computer file format designed primarily to store scanned images, especially those containing text and line drawings. It uses technologies such as image layer separation of text and background/images, progressive loading, arithmetic coding, and lossy compression for bitonal images. This allows for high quality, readable images to be stored in a minimum of space, so that they can be made available on the web.

DjVu has been promoted as an alternative to PDF, actually outperforming PDF on most scanned documents. The DjVu developers report that color magazine pages compress to 40–70KB, black and white technical papers compress to 15–40KB, and ancient manuscripts compress to around 100KB; all of these are significantly better than the typical 500KB required for a satisfactory JPEG image. Like PDF, DjVu can contain an OCRed text layer, making it easy to perform cut and paste and text search operations.