Re: OT: How do people set up long term development

[cgd at broadcom dot com]

At Wed, 28 May 2003 15:02:32 +0000 (UTC), "Michael Meissner" wrote:
> 1) Create my own CVS repository of a checked out releases, and check the files
>    into there.  Every so often, I will do a merge from the FSF sources to my
>    own repository.  This is how we did development at OSF, Cygnus, and Red Hat.
>    The problem is doing the merge step, and there isn't a direct correlation
>    between the versions in the master repository and my system.  If all of the
>    tools had CVS tags for nightly snapshots, it would make things easier, but
>    the bintuils directories don't seem to have snapshot tags.  This is the way
>    I'm leaning, since it will allow me to work on two systems (desk system,
>    laptop) and using cvs to do the update.

This is what I do.

To facilitate independent updates of different components, I prefer to
import each package separately (i.e., not a unified tree), and have my
build system worry about building them in the right order, etc.

(I'd revisit that somewhat if i were doing it again from scratch, but
I think if i had the same goal in mind that you do or that I did when
i created my current source tree, I'd probably do the same.)


The two real drawbacks of this (IMO) are:

* the build system can get a bit bit hairy.  8-)

* you have to do a bit of extra work to merge changes to the common
  components between the different parts of the source tree.  (e.g.,
  make opcodes changes?  Gotta change the copies of opcodes in
  binutils and gdb.)

It also chews more disk space and builds a few extra copies of things,
but disk is cheap and CPU is pretty cheap, too.


I also do my cvs imports in a special way, so that I have as much time
as I need to merge things.

basically, do:

	cvs import ... >& log_file

then run the script below against that log file.  any changes in any
imports need to be explicitly merged on to the trunk.

(One can approximate this procedure by using 'cvs commit -f' on one's
source tree, but that leads to bogus commits after the initial import,
and also newly-imported files automatically show up on the trunk.
ugh.  8-)

That way, if you try a snapshot from a night and it turns out not to
work, you don't have to commit it to the trunk.

beware: the script below doesn't do any cvs locking itself, and
requires local access to the CVS repository.  8-)


(BTW, if somebody's looking for a project to hack on, inside CVS, I'd
love to see the equivalent of the script below implemented as a 'cvs
import' option.  8-)



cgd
--
#!/bin/sh
# $Id: cvsimport_killnew,v 1.5 2003/01/16 01:27:55 cgd Exp $

# Script to kill revision 1.1 in files newly imported by CVS.
# See http://www.demetriou.com/~cgd/cvs for details.
#
# Written by Chris G. Demetriou <cgd@netbsd.org>.  Public domain.

fatal() {
	echo '***' $0: ERROR: $1 1>&2
	exit 1
}

usage() {
	echo usage: $0 logfilename 1>&2
	fatal usage
	exit 1
}

if [ -z "${CVSROOT}" ]; then
	fatal "CVSROOT is unset"
fi

logfile=$1
if [ -z "$logfile" ]; then
	usage
fi
if [ ! -f "$logfile" ]; then
	fatal "$logfile does not exist"
fi

awk '/^N / { print $2 }' "$logfile" | (
	set -e
	while read file; do
		repos_path=${CVSROOT}/${file},v 
		repos_dir=`dirname ${repos_path}` 
		repos_file=`basename ${repos_path}` 

		if [ ! -f $repos_path ]; then
			echo "Warning: $repos_path does not exist."
			continue
		fi

		echo "Fixing $file..."
		(
			# XXX error handling in this block is bogus...
			# a dir that won't (likely) be used.
			mkdir -p $repos_dir/CVS
			cd $repos_dir/CVS

			# reset default branch.
			rcs -b ../${repos_file} 

			# check in new rev w/ same contents.
			co -l -M ../${repos_file}
			ci -r1.2 -d -sdead \
			    -m"revision 1.1 was added on the vendor branch; delete from trunk" \
			    ../${repos_file}
		)
		rmdir $repos_dir/CVS || true

		echo "Moving $file to the attic..."
		mkdir -p ${repos_dir}/Attic 
		mv ${repos_path} ${repos_dir}/Attic/${repos_file} 
	done
)