Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: a few questions about cvs
From: Robert Collins <rbcollins AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: nigel gray <n_g_gray AT yahoo DOT de>
In-Reply-To: <Pine.GSO.4.44.0307041015570.17919-100000@slinky.cs.nyu.edu>
References: <Pine DOT GSO DOT 4 DOT 44 DOT 0307041015570 DOT 17919-100000 AT slinky DOT cs DOT nyu DOT edu>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ONS0oG3FhGx6JhWSqY9r"
Message-Id: <1057364085.23279.63.camel@localhost>
Mime-Version: 1.0
Date: 05 Jul 2003 10:14:46 +1000

--=-ONS0oG3FhGx6JhWSqY9r
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2003-07-05 at 00:20, Igor Pechtchanski wrote:

>=20
> Nigel,
>=20
> A local checkout of a cvs repository is no different than an extracted
> source tarball (except for the "CVS" subdirectories where cvs stores its
> administrative information). =20

Igor, this is not true in the general case. source tarballs often have
extra files, and more precise date stamps that CVS checkouts. For
instance, the cygwin setup source tarballs have correctly order date
dependencies on Makefile.am, Makefile.in, configure, configure.in etc. A
CVS Checkout will be missing Makefile.in and configure, (and when we had
those files in CVS, the dates where often the same, leading to them
being unnecessarily regenerated). Another class of files often in source
tarballs but not revision controlled (aka in CVS) is generated
documentation - say html made from .info, that the authors want everyone
to just get, and only have to need the appropriate tool chain if they
alter the documentation source.

> IOW, you should be able to just checkout the
> source from the repository (using a "cvs -d REPOSITORY checkout MODULE"),
> adapt it to your system (either by running "configure", if the project
> uses it, or by editing some header, which may not be necessary for a
> really portable project), and then run "make" and "make test".

You should read the README and INSTALL for the project. Often they will
also have a 'using CVS for developing X' page or document, which may
refer you to autoreconf, or ./bootstrap.sh. Follow the projects
directions... and you should be fine.

Lastly, there is usually a pattern of branches to the development, where
there may be a branch that is the latest stable version, and HEAD being
unstable - so something similar. So, you could grab the latest stable
version, and get CVS fixes for that, without suffering the unstable
bugs. This depends very much on how each individual project structures
its development...

Rob
--=20
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

--=-ONS0oG3FhGx6JhWSqY9r
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/Bhh1I5+kQ8LJcoIRAldeAJ9h4u8WYpH7jYiEfdqNsC2S+EvmiQCdGBYG
YQco8ZVFuwawrHreHWH1t3U=
=NG0F
-----END PGP SIGNATURE-----

--=-ONS0oG3FhGx6JhWSqY9r--