Re: Need CVS Help

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden writes:

> Hello Everyone,
> 
> This is my 2nd email to CVS, I have not recd. any response from CVS.

In 2005 (January thru the present), I have not received any e-mail from
a bncollege.com college address via address@hidden Are you certain
that your e-mail is reaching the address@hidden list? You may wish to
have your postmaster verify where your e-mail is going.

> We are in research to use CVS in our organization.

Researching your options is a good idea. Many different source control
systems exist out there and you should choose the one that is best
suited to your needs.

> I need to know how should we move the CVS from development environment to
> QA and from QA to Production environment, what are the procedures to do
> that and where can I can find the documentation for that.

Don't move it. Use a single repository for the full life-cycle of your
product. You may wish to consider using scripts like cvs_acls as a part
of your commit criteria to allow your QA and production folks to impose
a restricted set of folks that are able to commit to branches as well as
creating branches specifically for the QA and production phases.

In a typical life cycle you might have development committing changes
into the main trunk of the repository. At specified intervals, create a
branch from the mainline to be used by your QA folks to test various
release candidates. Only bug fixes to problems found in QA go into the
branch so created. At some point, QA blesses the contents of the branch
and hands off to production to create the official builds of your
product and create a release tag on those sources.

Everyone uses the same repository in a client/server mode and if there
is a need for development to handle bugs from customers, they will know
exactly what sources were used to build the product by being able to
check them out of their own repository with the release tag provided to
them by production.

If they need to produce a bugfix, create a branch based on the release
tag for that purpose and restrict the folks that can commit to it to
those who need to fix the customer bugs, have QA build from that branch
and release generate another official build from the branch and tag what
they built.

There are many other possibilities for proccesses.

However, if this is not suitable to your purposes, you may wish to
investigate other SCM tools.

> I have already searched your web site but I can not actually fine document
> for this.

Because no such document should exist. CVS is a concurrent versioning system.

> I am new to CVS control system, I have given a project to learn about CVS
> control system at my own, could you tell me what is the best way to learn
> fast and where to start from.

Books are good. Many exist on the topic of CVS.

Reading back issues of the info-cvs mailing list

    http://lists.nongnu.org/mailman/listinfo/info-cvs

may also help you.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFC4RSOCg7APGsDnFERAl2QAKDdiWAaD8uqZ4jTT8d5KUqrtVSfIACgimSf
Zu0wD1IpFfjq6fpoEeLvfpo=
=qlWN
-----END PGP SIGNATURE-----