INTERVIEW QUESTIONS CONFIGURATION MANAGEMENT TOOLS CVS DETAILS

Question: What is a Branch?

Answer: In general, a branch is any mechanism that allows one or more
developers to modify a file without affecting anyone other than
those working on the same branch.

There are four kinds of "branch" CVS can manage:

1. The Vendor Branch.

A single vendor branch is supported. The "import" command
takes a sequence of releases from a source code vendor (called
a "vendor" even if no money is involved), placing them on a
special "Vendor" branch. The Vendor branch is considered part
of the "Main line" of development, though it must be merged
into locally modified files on the RCS Main branch before the
"import" is complete.

See Section 3H ("import").

2. Your Working directory.

A checked-out working directory, can be treated like a private
branch. No one but you can touch your files. You have
complete control over when you include work committed by
others. However, you can't commit or tag intermediate versions
of your work.

3. A Development branch.

A group of developers can share changes among the group,
without affecting the Main line of development, by creating a
branch. Only those who have checked-out the branch see the
changes committed to that branch. This kind of branch is
usually temporary, collapsing (i.e. merge and forget) into the
Main line when the project requiring the branch is completed.

You can also create a private branch of this type, allowing an
individual to commit (and tag) intermediate revisions without
changing the Main line. It should be managed exactly like a
Development Branch -- collapsed into the Main line (or its
parent branch, if that is not the Main Branch) and forgotten
when the work is done.

4. A Release branch.

At release time, a branch should be created marking what was
released. Later, small changes (sometimes called "patches")
can be made to the release without including everything else on
the Main line of development. You avoid forcing the customer
to accept new, possibly untested, features added since the
release. This is also the way to correct bugs found during
testing in an environment where other developers have continued
to commit to the Main line while you are testing and packaging
the release.

Although the internal format of this type of branch (branch tag
and RCS branches) is the same as in a development branch, its
purpose and the way it is managed are different. The major
difference is that a Release branch is normally Permanent.
Once you let a release out the door to customers, or to the
next stage of whatever process you are using, you should retain
forever the branch marking that release.

Since the branch is permanent, you cannot incorporate the
branch fixes into the Main line by "collapsing" (merging and
forgetting) the release branch. For large changes to many
files on the release branch, you will have to perform a branch
merge using "update -j <rev> -j <rev>". (See 4C.7)

The most common way to merge small changes back into Main line
development is to make the change in both places
simultaneously. This is faster than trying to perform a
selective merge.

In general, a branch is any mechanism that allows one or more
developers to modify a file without affecting anyone other than
those working on the same branch.

There are four kinds of "branch" CVS can manage:

1. The Vendor Branch.

A single vendor branch is supported. The "import" command
takes a sequence of releases from a source code vendor (called
a "vendor" even if no money is involved), placing them on a
special "Vendor" branch. The Vendor branch is considered part
of the "Main line" of development, though it must be merged
into locally modified files on the RCS Main branch before the
"import" is complete.

See Section 3H ("import").

2. Your Working directory.

A checked-out working directory, can be treated like a private
branch. No one but you can touch your files. You have
complete control over when you include work committed by
others. However, you can't commit or tag intermediate versions
of your work.

3. A Development branch.

A group of developers can share changes among the group,
without affecting the Main line of development, by creating a
branch. Only those who have checked-out the branch see the
changes committed to that branch. This kind of branch is
usually temporary, collapsing (i.e. merge and forget) into the
Main line when the project requiring the branch is completed.

You can also create a private branch of this type, allowing an
individual to commit (and tag) intermediate revisions without
changing the Main line. It should be managed exactly like a
Development Branch -- collapsed into the Main line (or its
parent branch, if that is not the Main Branch) and forgotten
when the work is done.

4. A Release branch.

At release time, a branch should be created marking what was
released. Later, small changes (sometimes called "patches")
can be made to the release without including everything else on
the Main line of development. You avoid forcing the customer
to accept new, possibly untested, features added since the
release. This is also the way to correct bugs found during
testing in an environment where other developers have continued
to commit to the Main line while you are testing and packaging
the release.

Although the internal format of this type of branch (branch tag
and RCS branches) is the same as in a development branch, its
purpose and the way it is managed are different. The major
difference is that a Release branch is normally Permanent.
Once you let a release out the door to customers, or to the
next stage of whatever process you are using, you should retain
forever the branch marking that release.

Since the branch is permanent, you cannot incorporate the
branch fixes into the Main line by "collapsing" (merging and
forgetting) the release branch. For large changes to many
files on the release branch, you will have to perform a branch
merge using "update -j <rev> -j <rev>". (See 4C.7)

The most common way to merge small changes back into Main line
development is to make the change in both places
simultaneously. This is faster than trying to perform a
selective merge.
Source: CoolInterview.com

If you have the better answer, then send it to us. We will display your answer after the approval.

Rules to Post Answers in CoolInterview.com:-

• There should not be any Spelling Mistakes.
• There should not be any Gramatical Errors.
• Answers must not contain any bad words.
• Answers should not be the repeat of same answer, already approved.
• Answer should be complete in itself.

Name :*
Email Id :*
Answer :*
Verification Code	Not readable? Load New Code
Enter the above shown code: *
	Inform me about updated answers to this question