Introduction of CGI | What is Common Gateway Interface (CGI)?

cgi-introduction

Any Server will (mostly) do   

  • CGI will not work without a server
  • Your Server must allow CGI
  • Your CGI application must be written in a language supported by your server
  • You can use probably your existing web server
  • If you need to test on your local computer, you may install WAMP/XAMPP
  • Each Server has a particular requirements about running  CGI Applications

Prerequisties
Experience in relevant programming language

  • Perl
  • Php
  • Unix Shell
  • c/c++
  • HTML/CSS

What is CGI
Common Interface Gateway

  • How web browsers submit forms and interact with programs on the server
  • Used for simple interaction applications
  • Can be used with any programming language
  • Often called “CGI Scripts”
  • Can be written in any language
  • Run in the server, not in a web browser
  • Must follow server requirements for running applocations

ANY SERVER WILL (MOSTLY) do

  • CGI will not work without a web server
  • Your Server must allow CGI
  • Your CGI application must be written in a language supported by your server
  • You can use  your existing web server
  • If you need to test on your local computer, you may install WAMP/XAMPP

Some Guidelines for Unix/Apapche users

  1. Permission – 755 ( aka rwxr-xr-x)
  2. Filename associates
  3. .cgi, .pl, .php …etc
  4. .httaccess
  5. Options+ExecCGI
  6. AddHandle cgi-scripts .cgi
  7. SetHander cgi-script
  8. Access to server log

Some Guidelines for Windows Servers
Many Windows servers do not support perl or PHP
May require ASP or C#
Usually require specific filename extension
.pl for perl
.php for php
.asp or .aspx for ASP
Access to error log
Check with your server web site or support staff

How CGI works

  1. Browser Communicates with server over HTTP
  2. Browser sends a request to the server consisting of header and optional body
  3. Server sends information to the CGI application
  4. Environment variables
  5. Body may be sent in the STDIN stream
  6. Server sends a response consisting of a header and a body
Tagged : / / / / / / / / / / /

Depot Migration between perforce servers with history and change list

depot-migration-between-perforce-servers

There are many questions asked for the depot migration between server without losing any of the history  such as…

  • Moving depots across servers
  • Moving depots between servers
  • Move a product depot from one Perforce server to another
  • Depot Migration between perforce servers with history and change list

There are one solution which i find worth to try it out?
1.  Take A full backup of Source perforce server including jounals and file systems using checkpoint featres
2.  Then obliterate everything in the Source server that you didn’t want to copy – and remove redundant changelists with p4 change -f -d (refer p4 manuals)
3.  Go back to the Source server and obliterate the bit you’ve moved and remove redunant changelists again.
4. Now using p4merge tool, you can merger source and destination servers. this tools will help you for how to merge two separate servers into a single combined server using the Perfmerge++ utility.

What is Perfmerge++?
Perfmerge++ is a tool for merging two Perforce repositories to produce a third repository; it replaces the venerable perfmerge2.pl script. Unlike its predecessor, perfmerge++ does not work with checkpoints, rather it accesses the database files directly and creates new database files in the target directory. These new database files contain the merged content.

Reference:
http://kb.perforce.com/article/911
ftp://ftp.perforce.com/perforce/tools/perfmerge/perfmerge.html

Tagged : / / / / / / / / / / / / / / / / / / / / / / /

Introduction to CVS | Know ABout CVS | Quick Start Guide

cvs-introduction

Introduction to CVS

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.
CVS is a production quality system in wide use around the world, including many free software projects.
While CVS stores individual file history in the same format as RCS, it offers the following significant advantages over RCS:

  • It can run scripts which you can supply to log CVS operations or enforce site-specific polices.
  • Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
  • In cases where several developers or teams want to each maintain their own version of the files, because of geography and/or policy, CVS’s vendor branches can import a version from another team (even if they don’t use CVS), and then CVS can merge the changes from the vendor branch with the latest files if that is what is desired.
  • Unreserved checkouts, allowing more than one developer to work on the same files at the same time.
  • CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
  • CVS servers run on most unix variants, and clients for Windows NT/95, OS/2 and VMS are also available. CVS will also operate in what is sometimes called server mode against local repositories on Windows 95/NT.
Tagged : / / / / / / / / / / / / /