How to Write Trigger in Perforce? – Perforce Triggers Guide

trigger-in-perforce

1 Introduction
Perforce introduced the first server-side trigger in release 99.1 with the pre-submit trigger. This trigger satisfied a long-standing desire in the user community, but demand continued for more hooks. In release 2004.2, Perforce squarely hit the need with the addition of five new trigger types. Release 2005.1 adds yet one more trigger type to this list rounding out one of the categories of triggers to completeness. This paper discusses triggers, techniques for implementing them and purposes for using them. It presumes a general knowledge of scripting. The examples follow in several programming languages. They should be easy to follow with knowledge of general programming, and any more arcane constructs will be explained. The paper also presumes a reasonable knowledge of Perforce scripting alternatives, such as that presented in [Bowles2005]. Although this paper will address the scripting of triggers comprehensively, it will refer to other Perforce scripting contexts and to Perforce commands with an assumption of familiarity.

1.1 What is a trigger?
Triggers are programs that run on the server immediately in response to some welldefined event in Perforce. Therefore, the context for a trigger is running on the server
using the trigger mechanism to start. Triggers are typically written in a shell script such as Perl, Python or Ruby due to the flexibility and facilities they provide. However, triggers can be written in any programming language that can interface with Perforce, including UNIX shell (sh, ksh, csh and work-alikes) and compiled languages like C/C++.

1.2 Types of triggers
Triggers fall into two categories. Pre-submit triggers enable actions in response to the submission of changelists. Form triggers allow actions in response to various stages of the life cycle of a form, regardless of the form type. This section provides a brief overview of the trigger types in preparation for the more detailed discussion.
1.2.1 Pre-submit triggers
There are three types of pre-submit triggers corresponding to different points in the life cycle of a submission.
• “Submit” triggers execute after the changelist has been created but before the files have been transferred, allowing inspection of the changelist details but disallowing file inspection.
• “Content” triggers execute after file transfer but before commit, allowing for inspection of the files.
• “Commit” triggers execute after the commit, allowing inspection of the changelist and file contents, but disallowing canceling of the submission.

1.2.2 Form triggers
Form triggers come in four types depending on the point in the form’s life cycle in which they are invoked.
• “Out” triggers execute when the form is generated and can modify the form before it is presented to the user.
• “In” triggers execute when the form is sent back to Perforce but before it is parsed, also allowing modification of the form on its way in.
• “Save” triggers execute after the form has been parsed but before it is saved, allowing reaction to the form but not modification.
• “Delete” triggers execute before a form is deleted, allowing failure of the deletion.

1.3 Why use a trigger?
Knowing why to use a trigger is partially a matter of knowing what are the competing alternatives. The alternatives naturally come from other contexts, since triggers define a context of their own. This section details the salient operational characteristics of triggers and contrasts them with Perforce alternatives. The three primary alternatives to triggers are wrapper scripts, such as p4wrapper, 1 review daemons, and journal tailers. A variation on the wrapper script would be a script available from the Tools menu in P4Win.

1.3.1 Synchronous execution
Triggers execute synchronously in response to their associated event. This provides an immediacy of response that is sometimes required or at least highly desirable. One option that provides synchronous execution could be an action invoked from a wrapper script such as p4wrapper. Another option would be to forego synchronous execution and rely on frequently running review daemons. Journal tailers would also perform asynchronously, although with very rapid and event-driven response.
1.3.2 Immediate user feedback on error
Triggers can provide messages back to the user, but only on error. Messages are not delivered on successful execution. A wrapper script can deliver messages to the user regardless of whether an error occurs or not. Review daemons and journal tailers can only provide feedback through indirect mechanisms.
1.3.3 Enforceability
Enforceability refers to the ability of an administrator to ensure that the script will run regardless of the client program used to initiate the operation. Because triggers are
installed on and executed by the server in response to server events, they will execute regardless of the client program. Wrapper scripts will only be invoked when the wrapper is used, whereas direct use of p4 or use of a different client program will circumvent the desired action. Review daemons and journal tailers are also enforceable due to their context on the server.

1.3.4 Modify a form
Form triggers can modify a form as it is delivered to the user or as it is sent back to Perforce. Wrapper scripts share this characteristic. Review daemons and journal tailers can not modify forms except to the extent that any user or administrator can after the operation has finished.
1.3.5 Customize any action
Form triggers have a limited ability to customize actions that involve forms, but they do not have the ability to react to any arbitrary command. Similarly, pre-submit triggers can only react to submits. Review daemons can only react to commands whose side effects can be reliably observed, something that is not readily available from the command line in many cases or from review mechanisms. Journal tailers have the ability to react to any action that affects database entries, which includes almost all.
1.3.6 Optimization for bulk processing
The review mechanism gives the ability to process a large number of actions in an orderly and efficient manner as long as those changes impact a counter. This optimization is not readily if at all available to triggers, wrappers or journal tailers due to their association with individual commands or journal entries.

1.3.7 Deterministic execution
Triggers and wrappers provide an exact and deterministic understanding of when they will execute relative to the command that initiates them. Review daemons are generally driven in a time-based manner and therefore do not execute deterministically relative to the Perforce command. Journal tailers are closer to deterministic than review daemons, but can conceivably execute prior to completion of a command.
1.3.8 Summary
The following table summarizes the characteristics of the scripting contexts that compete with triggers for Perforce scripting.

 

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

List of 5 Common Problems in CVS – Troubleshooting Guide

cvs-common-problems

List of 5 Common Problems in CVS – Troubleshooting Guide

  • Problem 1:- How will we modify our conflict occurred files ?

While updating if you will get message like bellow, then check,

This will list:

* “A filename” for files that you added
* “M filename” for files that you modified
* “C filename” for files that have conflicts

Conflicts are files that you modified and that were modified on the head revision as well.

@ If u ll get C or conflict then go to that file and remove that lines and duplicate line then it will recover, it because, if more than two developer working on same file and comming on same time then conflict occures,

Files with conflicts will have conflict markers in them. Conflict markers look like:

<<<<<<< filename
your lines
=======
other person’s lines
>>>>>>> current version

  • Problem 2:-

If you are using your colleague’s checked out code for some changes, after that If you made any changes in code and then if you will try to check-in the code in CVS from your machine,after that if  it will ask your colleague’s password for checking-in. So How will we resolve this one ?


Soln:-
Please fine the CVS dir on your present code directory, then go to CVS dirctory, there, you will find Entries, Root, Repository like files , So now open that Rot file and change that username then your problem will solve, else let me know.
Steps:
cd CVS
vim Root
edit present urername to your username
@cvs:
:wq   // save and quit
cd ..  // come to parent directory
then do your work ..
it will fine

  • Problem 3:-
    Is there any way to identify the information of deleted lines in a file through CVS annotate or any other means?

Soln:-

         You deleted from CVS or local server ? if u deleted from both server then i have to see, else if u deleted from      either local server or CVS server  then do “cvs -q up -Pd  “

else do cvs -q up -Pd -r  ” .

  •  Problem4:-

           When I view the “cvs log”, the log report is fetching the file but says

            “date: 2008/12/31 06:00:51;  author: amareshcd;  state: Exp;  lines: +0 -0”
But I have added with 130 lines. Why the log is not showing “+130 -0” in its report.   ?

Soln:-

Use ,“cvs log -d date1 logfile.log”

  •  Problem5:-

        I have files that went into the Attic.  How do I restore them back? Viewing  the files  revealed that they’re in DEAD State. Someone has ‘cvs remove’d the files. Just restore them with ‘cvs add’. How ?

Soln:-

Step1:-
cvs log
Step2:-
Find til newest non-dead version
step 3:-
cvs update -r
step4:-
mv foo
step 5:-
cvs update -A
step 6:-
mv foo
step 7:-
cvs add
step 8:-
cvs commit -m “bring out your dead”

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

Makefile – Makefile example – Makefile Guide

makefile-example

Note that this example Makefile is from an older software project, which specifies everything within each makefile rather than using any recursive or inclusion-based makefile hierarchy, and is presented here for the purposes of the C intro project only. It is modified from the original for the purposes of the C intro project.

CC=             gcc
CFLAGS=         -Wall -O2 
LFLAGS+=

SRCS= cas.c \
client.c \
hashtable_itr.c

OBJS= ${SRCS:.c=.o}

all: libmarquis.a libmarquis.so

clean:
rm -f libmarquis.a libmarquis.so *.o

libmarquis.a: ${OBJS}
ar -r $@ ${OBJS}

libmarquis.so:${OBJS}
${CC} -shared ${CFLAGS} -fPIC -Wl,-soname,libmarquis.so -o $@ \
${OBJS}

.c.o:
${CC} ${CFLAGS} -c $<
—————

Tagged : / / / / / / / / /

How CVS will help to Realtime Developers ?

how-cvs-will-help-to-realtime-developers

CVS Tips & Tricks

The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.

Viewing the commit log of a file.

$ cvs log filename

Show current status of a file.

The status command will show you the latest version, the version in your working directory and if your local copy has been modified.

$ cvs status filename

Performing a CVS diff

After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.

  1. Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2
  1. Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename
  1. Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename
  1. Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename
  1. Perform a diff between working version and a specific database version:
$ cvs -q diff -u -r version filename

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

$ cvs status filename

To retrieve the entire change log pertaining to a file run:

$ cvs log filename

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

$ cvs -q up -Pd -r revision filename
  • To get the revision number use the log command above

Tag file in CVS as a Release

To tag files in CVS as a release perform the following:

$ cvs tag
  • Run the command from within the release source dir.

Creating a Branch

I like to do the following before creating a branch:

See what tags are available and pick one.

$ cvs -q log filename

Revert to a tagged version of HEAD.

$ cvs -q up -r TAG_Version

To create a branch in CVS perform the following:

$ cvs tag -b

Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.

cvs -q up -r
$ cvs -q status <– confirm that the branch has specified as the tag
$ cvs tag _mm_day_year <– eg: BRANCH_12_BUG_12345_07_17_2009

Reverting to a Branch

To revert to a branch in CVS perform the following:

$ cvs -q up –r
  • Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.

Verifying you are in a branch

To verify you are in a branch

$ cvs -q status

You will see that the branch is a sticky tag.

Merge Current Branch with HEAD

Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.

$ cvs update -j

This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:

$ cvs -q diff -u -r | less

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

$ cvs tag

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

$ cvs update -j -j

This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the –kk option will avoid this problem. But then you won’t see which files have changed and You won’t know who last modified a file easily. After you run this command I recommend:

$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`

You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087

This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.

Merge HEAD into Current Branch Multiple Times (with tags)

To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:

$ cvs update -kk -j -j
  • Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:
$ cvs update -kk -j UPDATE_HEAD_36_BUG__06_16_2008 -j UPDATE_HEAD_36_BUG__07_23_2008

The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the “old” tag, and the new tag will be created at the time of the merge.

The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn’t get flagged as a conflict on every merge/join.

Merge HEAD into Current Branch Multiple Times (without tags)

If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:

$ cvs update -kk -j Tag_Branch -j HEAD>

Run the command from within the branched version.

———————————-
To Avoide network confusion :-

use :- alias cvs=`cvs -z9`

causes cvs to use compression level 6.

Good links for it:-

  • http://datagrams.blogspot.com/2009/01/how-to-deploy-cvs-concurrent-versions.html
  • http://kb.wisc.edu/middleware/page.php?id=4087
  • http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_10.html#SEC85
  • http://ximbiot.com/cvs/wiki/Special/Index
  • More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

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

DOS TUTORIAL : THE BASICS | MS-DOS Learning Resources

dos-tutorial

DOS TUTORIAL : THE BASICS
Compilation by Lisa Lemieux, UC Call Center
Table of Contents
I. Lesson 1
  A. Hardware and Software differences.
B. What is DOS?
  C. Why You Need DOS.
  D. Set the Date and Time.
  E. Check the Date and Time.
II. Lesson 2
  A. Directory Command.
  B. Scroll Through the Directory Listing.
  C. Pause a Directory Listing.
  D. View a Wide Listing of Files.
  E. Recall a DOS Command.
  F. Print a Directory Listing.
  G. Check for a Single File.
  H. Check for a Group of Files.
  I. List Files with the Same Extension.
  J. Clear the Screen.
III. Lesson 3
  A. Create a DOS File.
  B. Copy a File.
  C. Copy a File with a New Extension.
D. Type a File with DOS.
E. Rename a File
F. Rename a Group of Files
IV. Lesson 4
A. Create a Subdirectory.
B. Move to a Subdirectory.
C. Set the DOS Prompt.
D. Move to the Parent Directory.
E. Copy a File into a Subdirectory.
F. Copy a Group of Files into a Subdirectory.
G. List Files in the Root from the Subdirectory.
H. Select the Directory List.
I. List Subdirectories.
V. Lesson 5
A. Delete a Single File.
B. Delete a Group of Files.
C. Delete all Files in a Subdirectory.
D. Remove a Subdirectory.
VI. Lesson 6
A. Format a Floppy Disk.
B. Change the Default Drive.
C. Diskcopy Command.
D. Copying a File from the Hard Drive to a Floppy.



Before you begin this tutorial
, please make sure that your prompt is C:\> If it is not, please do the following:
Directions:
1. Type: c:
2. Type: cd..
This should place you into the C:\> working directory.
NOTE: DOS is not case sensitive; therefore, a command can be entered in with CAPITAL LETTERS, lower-case letters, or a MiXtuRe of the two.


Hardware and Software Differences
There are two parts to a computer system, the hardware and the software. Hardware refers to the physical components of a computer. An example of hardware components would be the monitor, keyboard and mouse. Software represents the programs which contain a set of instructions written to perform a certain task on the computer.

What is DOS?
DOS stands for Disk Operating System. DOS controls the computer’s hardware and provides an environment for programs to run. This system program must always be present when working with your computer.

Why You Need DOS
There are a variety of reasons why you need DOS. A few of them are listed below to satisfy your curiosity.
1. DOS controls the flow of information between you and the computer (translator).
2. DOS allows you to store information on your computer.
3. DOS allows you to retrieve information stored on your computer.
4. DOS interprets and translates the software you have on your computer.
5. DOS gives you access to all its function (i.e. saving, copying, and printing files).

Set the Date and Time
Most computers on campus have an internal clock that will automatically set the date and time for you when you turn the computer on. However, if your computer does not have this feature or your computer has two floppy drives, you will need to do the following steps to set the date and time.
Directions:
1. Type the date like this: 1-15-97
2. Press the return key (enter key).
3. Type the time like this: 8:46
4. Press return.
5. Notice that the C:\> prompt will appear.
DOS marks the date and time on everything you do. It is important to periodically check the date and time if you have an internal clock to see if it is correct. If you have a two floppy system, it is important to enter the correct date and time when you turn the computer on.
NOTE: Baynan sets the date and time for you automatically when you Login.

 Check the Date and Time
DOS will let you check or change the date and time once it has been set. The procedure to do this is as follows:
Directions:
1. Type: date and press return.
2. If the correct date is displayed, simply press return. If the date is incorrect, type the correct date and press return.
3. Type: time and press return.
4. If the correct time is displayed, simply press return. If the time is incorrect, type the correct time and press return.

Directory Command
The DIRECTORY command is like a table of contents in a book. This directory will list the following information:

  • Filenames
  • File extensions
  • Size of each file
  • Date and time the file was last updated.

Directions:
1. At the C:\> type: dir and press return.
2. The list of files will scroll up and off the screen.
NOTE: At the end of the listing, there is a line that shows the number of bytes free on the hard drive.

Scroll Through the Directory Listing
When you type the DIR command and press return, the files begin to scroll vertically on your screen. If you have a lot of files it is difficult to read each one. By holding down the Control Key (CTRL) and the letter S at the same time, you are able to freeze the listing to view your files. When you are finished, press the spacebar for the list to continue.
NOTE: You must return to the C:\> before entering your next command.

Pause a Directory Listing
You can add a PAUSE command to your directory command which will allow you to view your directory one screen at a time.
Directions:
1. Type: dir/p and press return.
2. The screen freezes after it fills the screen with the files that are listed first in the directory.
3. Press the spacebar to continue listing you files.
4. Continue to press the spacebar until you return back to the C:\> prompt.

 View a Wide Listing of Files
When you need to quickly view your files, you can add a /W to the directory command. This will display your files into five columns on the screen.
Directions:
1. Type: dir/w and press return.
2. DOS will list only the name of you file and the file extension on the screen.
NOTE: Use this command when you are not concerned with looking at the file size or the date it was created.
Recall a DOS Command
The F3 function key can be used to recall the last DOS command you typed in. If you would like to retrieve a previously entered command, you can also press the up arrow key continuously until you reach the desired command you were looking for.
NOTE: You can also type out each letter in your last command by using the right arrow key or the right cursor key. After you use the F3 key to recall a command, you can use the backspace key to edit any part of the command or add to your command.

Print a Directory Listing
You can print a list of your files in your directory by instructing DOS to send the information to your printer.
Directions:
1. Type: dir>prn and press return.
2. The > symbol stands for output. The PRN stands for printer.
NOTE: You can print a wide listing of your files by typing dir/w>prn
Laserjet printers and other sheetfeeder printers will not eject the page after the dir>prn command. You must take the printer off-line and press the form feed button. Remember to press the on-line button when you are done in order to continue using the printer.

Check for a Single File
Instead of using the directory command to look for one particular file, you can type the name of the file after the DIR command at the C:\> prompt.
Directions:
1. Make sure that you are at your C:\> prompt.
2. Type: dir format.com (filename.extension) and press return.
3. The screen will display a listing of the file or a file not found message.

Check for a Group of Files
The * symbol is referred to as a wildcard and stands for any character or group of characters. This is helpful when you want to list files that start with a particular letter or group.
Directions:
1. Type: dir c* and press return.
2. All filenames that begin with the letter C will be listed.
3. Press the F3 key.
4. Backspace twice and replace C* with A* and press return.
5. All filenames that begin with the letter A are listed.

List Files with the Same Extensions
You can also use the wildcard character * to look for a group of files with the same extension.
Directions:
1. Type: dir *.bat and press return.
2. All files with the .bat extension are listed.
3. Press the F3 key.
4. Backspace three times and replace the .bat extension with the .sys extension and press return.
5. All files with the .sys extension should now be listed.

Clear the Screen
When the screen get full of information, you may want to clear it. To do this, type CLS at the C:\> prompt and press return.

Create a File with DOS
Directions:
1. Type: copy con Quick.ltr and press return.
2. Type this message in the following format:
Bob
Sales are up 15%.
Good Job!
Craig
3. Press the F6 function key (^Z) and press return.
4. DOS gives you a message that 1 File(s) has been copied.
5. Type: dir q* and press return.
6. Now you can see the list of files beginning with the letter Q.
NOTE: You can also use the COPY command to print a file by typing: copy quick.ltr prn and press return.

Copy a File
You can use the COPY command to copy one file to another.
Directions:
1. Type: copy quick.ltr quick2.ltr and press return.
2. DOS will tell you one file has been copied.
3. Type: dir q* and press return.
4. You should have two files listed with different names.
NOTE: Filenames cannot be more than eight characters in length. File extensions cannot be more than three characters in length.

Copy a File with a New Extension
You can also use the COPY command to copy the file with a different filename extension.
Directions:
1. Type: copy quick.ltr quick.bac and press return.
2. Type: dir q* and press return.
3. Three files should be listed.

Type a File with DOS
If you need to check the contents of a particular file or any DOS file, you will need to use the TYPE command.
Directions:
1. Type: type quick2.ltr and press return.
2. DOS prints the contents of the file.
NOTE: Never use the TYPE command with files that have the .com, .exe, .sys, and .bas extensions. These are program files and will only display junk on the screen.

Rename a File
The RENAME command lets you rename a previous file with a new name.
Directions:
1. Type: ren quick2.ltr sales.ltr and press return.
2. Type: dir *.ltr and press return.
3. DOS lists only two files that have the .ltr extension: quick.ltr and sales.ltr.

Rename a Group of Files
With the wildcard character *, you can also use the RENAME command to change a group of files.
Directions:
1. Type: ren *.ltr *.bob and press return.
2. Type: dir *.bob and press return.
3. You should have two files listed with a .bob extension.
4. Type: dir *.ltr and press return.
5. There should be no files found with .ltr extensions.
NOTE: You can also rename a group of files that have the same name but different extensions. Type the RENAME command then the filename followed by the dot and the wildcard, space and then type the new filename followed by a dot and the wildcard character. It will look like this: filename.* newfilename.*
Create a Subdirectory
To create a subdirectory, you will need to use the MAKE DIRECTORY command, a.k.a. MD. The MD command is useful for organizing files on your hard drive. With subdirectories, you can create and store related files together. For example, one subdirectory could be used to store all word processing files and another for all spreadsheet files.
Directions:
1. Type: md \info and press return.
2. Type: dir *. and press return.
3. Notice the *. will list only the subdirectories.

Move to a Subdirectory
Once you have created a subdirectory, to move to that directory, you will use the CHANGE DIRECTORY command, a.k.a. CD.
Directions:
1. Type: cd \info and press return.
2. Type: cd and press return.
3. The name of the directory is listed.

Set the DOS Prompt
You can set or change the standard system prompt to display the name of the directory or subdirectory you are currently working in.
Directions:
1. Type: prompt $p $g and press return.
2. The DOS prompt tells you that you are working in the C directory (drive) and in the Info subdirectory.
3. Type: dir and press return.
4. The single dot stands for the current directory. The double dots stand for the parent directory (root). The dots are often referred to as place markers.

Move to the Parent Directory
DOS has a quick way to move from the current directory back to the parent directory.
Directions:
1. Type: cd.. and press return.
2. You will return back to the C:\> prompt.
Copy a File into a Subdirectory
The COPY command lets you copy files from one directory to another.
Directions:
1. Type: copy sales.bob \info and press return.
2. Type: dir \info and press return.
3. Notice that a copy of Sales.bob is copied into the subdirectory Info. The original file is also in the root directory.

Copy a Group of Files into a Subdirectory
When copying a group of files from the root directory into a subdirectory, it is necessary to use the wildcard character * along with the COPY command.
Directions:
1. Type: copy quick.* \info and press return.
2. DOS will list the files being copied.
3. Type: dir \info and press return.
4. Three files should be listed in the Info subdirectory.
List Files in a Subdirectory
The CHANGE DIRECTORY, a.k.a. CD, command will let you list files in your subdirectory from your hard drive.
Directions:
1. Type: cd \info and press return.
2. Type: dir and press return.
3. All files in the Info subdirectory are listed.

List Files in the Root from a Subdirectory
The DIRECTORY command is also used to get a listing of all the files in the root directory while in a subdirectory. The backslash character \ represents the root directory.
Directions:
1. Type: dir \ and press return.
2. All the files in the root directory are listed.

Select the Directory List
To look for a specific filename extension, you can use the SELECTED DIRECTORY command.
Directions:
1. Type: dir \*.bat and press return.
2. Only the files with the .bat extensions are listed.
3. Press the F3 key.
4. Backspace three times.
5. Type: sys and press return.
6. Now only the files with the .sys extensions are listed.

List Subdirectories
Directions:
1. Type: dir \*. and press return.
2. All the subdirectories are listed.
NOTE: The backslash character \ directs DOS to read from the root directory. The *. requests the listing of the subdirectories.

Delete a Single File
Periodically it is a good idea to delete files from the hard disk which are no longer needed or used. DOS makes it easy to remove these files with the DELETE command, a.k.a. DEL.
Directions:
1. Type: cd.. and press return.
2. The prompt shows you that you are back in the root directory.
3. Type: del sales.bob and press return.
4. Type: dir Sales.bob and press return.
5. Sales.bob is no longer listed because it has been deleted.

Delete a Group of Files
By using the wildcard character * you can delete a group of files from you hard drive.
Directions:
1. Type: del quick.* and press return.
2. Type: dir quick.* and press return.
3. All Quick files have been deleted.

Delete all Files in a Subdirectory
There are two rules you will need to follow before removing a subdirectory.
RULE 1: All files in the subdirectory must be deleted.
NOTE: Never type DEL *.* when you are in the root directory. It will destroy all DOS files that are necessary to boot and operate the computer.
Directions:
1. Type: cd \info and press return.
2. Type: dir and press return.
3. Three files should be listed.
4. Type: del *.* and press return.
5. DOS will ask you if you are sure? (Y/N)
6. Type: Y and press enter.
Now that your subdirectory is empty, you can delete the subdirectory (see rule 2 below).

Remove a Subdirectory
RULE 2: You cannot be in the subdirectory that you wish to remove. You will need to return to the root directory (C:\> prompt).
Directions:
1. Type: cd.. and press return.
2. You should be back in the root directory.
3. Type: rd \info and press return.
4. Type: dir *. and press return.
5. Notice that the Info subdirectory is no longer listed.

Format a Floppy Disk
Before you can use a disk, you must format it.
Directions:
1. At the C:\> prompt type: format a:
2. The A drive will be the drive that you insert your disk into; hence, the a: after the Format command and press return.
3. You will be prompted with the message: “Insert new diskette for drive A: and press enter when ready.”
4. Now insert the disk you wish to format and press return.
5. Once this formatting process is done, the following message will appear: “Format Completed.” Then you will be prompted for a volume label. Simply press return again.
6. Now you will be asked if you would like to format another disk (Y/N)? Press N.
NOTE: If you receive a message like: “Track 0 bad” or “Disk unusable,” your disk may be the wrong capacity. You can get help with this error message by typing:
Help Format.

Change the Default Drive
To change from your hard drive to a floppy drive, you will need to indicate this change as follows:
Directions:
1. Put a floppy disk into drive A.
2. Type: a: and press return.
3. Your prompt should change to A:\>
4. Type: dir and press return.
5. You are now able to see all the files on the floppy.
6. To change back to your hard drive, you will need to reverse this procedure.
7. Type: c: and press return. Now your prompt should be C:\>

Diskcopy Command
Sometimes there is a need to copy all the files on one floppy diskette to another floppy. First you will need a blank formatted disk (refer to section on formatting disks.)
Directions:
1. Type: diskcopy a: a: and press return.
2. When asked to put in the source disk, put in the diskette that has the information you want to copy into drive A and press return.
3. Wait a few seconds. When asked to insert a target disk, take out the diskette from drive A and insert the blank floppy disk and press return.
4. Once this process is complete, you will be prompted to write to another duplicate diskette (Y/N). Press N.
5. Then you will be prompted to copy another disk (Y/N)? Press N.
NOTE: If your machine has two floppy disk drives, insert the original (source) disk into drive A and the blank (target) disk into drive B. Then type: DISKCOPY A: B:

Copying a File from the Hard Drive to a Floppy Disk
Sometimes there is a need to copy a file from the hard drive onto a floppy disk. This is helpful if you would like to have an extra copy of a certain file as a backup or to transport the copied file to another computer.
Directions:
1. Type: copy a: and press return.
2. Wait for a few seconds, notice the red light on the floppy drive. Never attempt to remove a disk from the disk drive while this red light is on.
3. To check to see if the file was copied, type a: at the C:\> prompt and press return.
4. Type: dir and press return.

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

What are the Best Practices of CVS?

cvs-best-practices

CVS Best Practices

 

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

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

Apache Ant: Learn Apache Ant from IBM Experts

learn-apache-ant-from-experts

Apache Ant: Learn Apache Ant from IBM Experts

Section 1. Getting started 

  
What is this tutorial about?
In this tutorial, you’ll learn about Ant, a build tool for Java TM projects. Ant has quickly become popular among Java developers because of its flexibility and ease of use, so you it owe it to yourself to find out more about it. You don’t need any prior experience with or knowledge of Ant before you proceed. We’ll first see the basic structure of Ant build files, and learn how to invoke the tool. We’ll walk through the steps involved in writing a build file for a simple Java project, and then look at some of Ant’s other useful functions, including filesystem operations and pattern matching. We’ll finish by writing our own Java class that extends Ant’s functionality. In the course of the tutorial, we’ll show you how to run Ant both from the command line and from within the open source Eclipse IDE. You don’t need both environments.

Section 2. Ant basics

Ant basics introduction
In this section, we’ll give you an overview of Ant’s capabilities and strengths, and discuss its history and rise in popularity. We then delve straight into the fundamentals of Ant by examining the basic structure of a minimal build file. We’ll also introduce the concepts of properties and dependencies. What is Ant? Apache Ant is a Java-based build tool. According to its original author, James
Duncan Davidson, the name is an acronym for another neat tool. Build tools are used in software development to transform source code and other input files into an executable form (and maybe into installable product images as well). As an application’s build process becomes more complex, it becomes increasingly important to ensure that precisely the same build steps are carried out
during each build, with as much automation as possible, in order to produce consistent builds in a timely manner. Traditional projects in C or C++ often use the make tool for this purpose, where the build tasks are performed by invoking shell commands, and dependencies are defined between each of the build tasks so that they are always performed in the necessary order.
Ant is similar to make in that it defines dependencies between build tasks; however, instead of implementing build tasks using platform-specific shell commands, it uses cross-platform Java classes. With Ant, you can write a single build file that operates consistently on any Java platform (as Ant itself is implemented in the Java language); this is Ant’s greatest strength.
Ant’s other key strengths are its powerful simplicity and its ability to be seamlessly extended with custom capabilities. Hopefully, you will appreciate these strengths after completing the rest of this tutorial.
A little history
Ant started out as an internal component of Tomcat, the servlet container that is used in the reference implementation for the Java Servlet and JavaServer Pages (JSP) technologies. The Tomcat codebase was donated to the Apache Software Foundation; there, it became part of the Apache Jakarta project, which has a mission to produce open source, server-side solutions for the Java platform. The
usefulness of Ant was quickly recognized and its usage spread throughout the other Jakarta subprojects. Thus, it was made into a Jakarta subproject of its own, with the first independent release being made in July of 2000. Since then, Ant’s popularity has grown and grown. It has won numerous industry awards and become the de facto standard for building open source Java projects. In
November of 2002, this success was acknowledged by Ant’s promotion to a top-level Apache project. At the time of writing, the current stable release of Ant is 1.5.4, which supports all
JDK versions from 1.1 onwards. Beta versions of the next release, 1.6, are also available; these require JDK 1.2 or later. Planning is also underway for a future 2.0 release, which will involve a major rearchitecture. Ant 2.0 will feature improved consistency and enhanced functionality, whilst still retaining Ant’s core goals of simplicity, ease of understanding, and extensibility.
Anatomy of an Ant build file
Ant does not define its own custom syntax; instead, its build files are written in XML (see Resources ). There are a defined set of XML elements that Ant understands, and, as you’ll see in a later section, new elements can be defined to extend Ant’s capabilities. Every build file consists of a single top-level project element, which in turn contains one or more target elements. A target is a defined step in a build that performs any number of operations, such as compiling a set of source files. The operations themselves are performed by other specialized task tags, as we’ll see later. These tasks are then grouped together into target elements, as desired. All of the operations required for a build could be placed into a single target element, but that would reduce flexibility. It is usually preferable to split the operations into logical build steps, with each step contained in its own target element. This allows you to perform one individual part of the overall build without necessarily performing other parts. For instance, by only invoking certain targets, you could compile your project’s source code without creating an installable project image. The top-level project element needs to contain a default attribute that specifies the target to be executed if none is specified when Ant is invoked. Then the target itself needs to be defined, using the target element. Here is a minimal build file:

Note that this is well-formed XML, with an XML declaration specifying the version of XML being used (this is not currently required by Ant, but it is good practice), and with every element being properly closed. It is also possible to open and close an element in one go. So, instead of the separate start and end tags for the target element above, we could have written it as follows:

This more concise form can be clearer when an element doesn’t have any enclosed content.

Adding descriptions
The build file we saw in the previous section is nice and concise, but it doesn’t say much about the actual project being built. There are a number of ways to make it more descriptive without changing the functionality. Here’s an example:

A simple project introducing the use of descriptive tags in Ant build files.

As you can see, XML comments can be used throughout build files to improve clarity. Also, Ant defines its own description element and description attribute, which can be used to provide more structured annotations.

Properties
Properties in Ant are like programming language variables in that they have a name and a value. However, unlike normal variables, properties in Ant cannot be changed once they have been set; they are immutable, like String objects in the Java language. This might seem restrictive at first, but it is in keeping with Ant’s philosophy of simplicity: after all, it is a build tool, not a programming language. If
you do attempt to give an existing property a new value, this isn’t treated as an error, but the property does retain its existing value. (This behavior can be useful, as we’ll see.)
Based on the descriptive names of the elements and attributes seen so far, it should come as no surprise that the mechanism for setting properties in Ant looks like this:

To refer to this property in other parts of the build file, you would use this syntax: ${metal} For example, to use the value of one property as part of the value of another, you would write a tag that looks like this:

 

There are number of predefined properties in Ant. Firstly, all of the system properties set by the Java environment used to run Ant are available as Ant properties, such as ${user.home}. In addition to these, Ant defines a small set of its own properties, including ${ant.version}, which contains the version of Ant, and ${basedir}, which is the absolute path of the project’s directory (as defined by the directory containing the build file, or by the optional basedir attribute of the project element). Properties are often used to refer to files and directories on the filesystem, but this could cause problems across different platforms with different path separator characters ( / versus \, for example). Ant’s location attribute is specifically designed to hold filesystem paths in a platform-neutral way. You would use location in place of value like so:

 

The path separator characters used for the location attribute are converted to the correct ones for the current platform; and, as the filename is relative, it is taken to be relative to the project’s base directory. We could just as easily have written this instead:

 

Both versions of this tag will behave in the same fashion across different platforms. The only thing to avoid if portability is required is DOS-style drive letters in
filenames. It is also more flexible to use relative path names instead of absolute ones where possible.

Defining dependencies
Building a project generally requires a number of steps — first compiling source code and then packaging it into Java Archive Files (JARs) files, for example. (See Resources for more information on using JARs.) Many of these steps have a clearly defined order — for instance, you can’t package the classfiles until they have been generated by the compiler from the source code. Instead of specifying the targets in sequence order, Ant takes the more flexible approach of defining dependencies, just as make and similar build tools do. Each target is defined in terms of all the other
targets that need to be completed before it can be performed. This is done using the depends attribute of the target element. For example:

 

This approach allows you to request a build of any stage of the project; Ant will execute the defined prerequisite stages first. In the example above, if you ask Ant to developerWorks® ibm.com/developerWorks complete the compile step, it determines that the targets init and preprocess need to be executed first. The init target doesn’t depend on anything, so that will
be executed first. Then Ant will look at the preprocess target and find that it depends on the init target; because it has already run that, it doesn’t do so again, and executes the preprocess target. Finally, the compile task itself can be executed. Note that the order in which the targets appear in the build file is not important: it is only the depends attributes that determine execution order.

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

AnthillPro 3.6 Released – What’s New Features in AnthillPro?

anthillpro-new-version

Major New Features In AnthillPro 3.6

 

Improved support for geographic distribution. The server-agent communication layer has been reworked for better performance. The new approach also supports the use of a Relay Server that acts as a proxy for agents behind a firewall or in another location. Distributed web front ends can also be employed to improve responsiveness for users connecting over the WAN.

Preflight builds. At the push of a button, preflight builds integrate the developer’s changes with a snapshot of the latest source code, and then run a build in the build environment, not on the developer’s machine. If a Preflight Build fails, the developer is immediately notified.

Test and coverage trending and metrics. Discover test and coverage trends. Compare any two builds and see which tests and suites fail the most or take the longest. Or see if coverage is improving or decreasing.

 

New and Improved Integrations

  

EMMA code coverage integration. Run EMMA and publish coverage reports with the EMMA integration. In addition, AnthillPro users can generate a coverage report for every project that uses EMMA.

Mercurial integration. Set up AnthillPro projects that use the Mercurial repository to check out code, build, tag, and more.

AccuRev integration expanded. AnthillPro can now automatically generate and manage a pool of AccuRev streams, making configuration and maintenance easier.

Team Foundation Server 2005 and 2008 are now supported concurrently.

Jira Integration updated. AnthillPro can now update issue status and leave a comment regarding what it did.

  

Other Improvements

 

 Remote agent management. Agents can be restarted from the main UI.

 Easier view of source code changes across builds. Any two builds can be compared with AnthillPro listing the changes between them as well as changes to their dependencies.

 Copying projects, workflows and jobs has been made easier and more flexible.

 The types of user defined workflow properties can now be changed. Fields can also be marked as password fields.

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 : / / / / / / / / / / / / /

CVS Best Practices – List of CVS Best Practices – CVS Tips

cvs-best-practices

CVS Best Practices

These are list of CVS Best Practices:

* Don’t share workspaces

Sharing workspaces compromises CVS’s ability to track activity by user or task.

* Don’t work outside of managed workspaces

CVS can only track work in progress when it takes place within managed workspaces. Never copy files from others sandboxes or even from outside your sandbox since you may overwrite somebody else’s code.

* Don’t use jello views

A file in your workspace should not change unless you explicitly cause the change. A “jello view” is a workspace where file changes are caused by external events beyond your control e.g. workspace built upon a tree of symbolic links to files in another workspace.

* Stay in sync with the codeline

The quality of your work depends largely on how well it meshes with others work. In other words, as changes are checked into the codeline, you should update your workspace and integrate those changes with yours. Update your code at least once in the morning daily.

* Checkin code daily

Integrating your development work with other peoples’ work also requires you to check in your changes regularly. Don’t keep your new code lying in your workspace for many days at a time. This may lead to many conflicts at a later stage when you try to merge.

* Never check in without compiling and testing your code

* Always update your modules/ files and resolve any conflicts before committing

* After committing changes, diff with previous version to make sure you did not accidentally overwrite anybody else’s code

* If you overwrite somebody else’s code, rollback

* Always communicate any changes you commit, to all those concerned with the module/ file that was changed

* Always add comments when committing changes

Good and meaningful comments make it easy for others to know exactly what was changed. For e.g. if it’s a bug fix it should have a Bug Number.

* Add whitespaces with discretion

Changes to whitespaces cause unnecessary updates to happen and may show conflicts during merges

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