Re: Best method to produce patches?

2003-02-12 Thread David O'Brien
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote:
 I am about to try to make some changes to FreeBSD current...
 
 Should I begin to use read-only CVS instead of CVSup for this work or 
 is it possible to generate diffs based on CVSup'd sources?

For light duty usage (esp. on a RELENG_X branch), I just use an anoncvs
server, such as anoncvs.de.freebsd.org.  This saves you the disk space,
but still allows you to produce diffs.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Best method to produce patches?

2003-02-11 Thread Hiten Pandya
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote the words in effect of:
 I am about to try to make some changes to FreeBSD current...
 
 Should I begin to use read-only CVS instead of CVSup for this work or 
 is it possible to generate diffs based on CVSup'd sources?
 
 What is the recommend method to use for playing with the source?
 
 I already found a small change in libc that should probably get 
 committed but I want to generate the patch properly for everyone's 
 approval.

Checkout the development(7) manual page, written by Matt Dillon.
Cheers.

-- 
Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED])
http://www.unixdaemons.com/~hiten/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Best method to produce patches?

2003-02-10 Thread David Schultz
Thus spake David Leimbach [EMAIL PROTECTED]:
 I am about to try to make some changes to FreeBSD current...
 
 Should I begin to use read-only CVS instead of CVSup for this work or 
 is it possible to generate diffs based on CVSup'd sources?
 
 What is the recommend method to use for playing with the source?
 
 I already found a small change in libc that should probably get 
 committed but I want to generate the patch properly for everyone's 
 approval.

The best thing to do is to have a local copy of the entire
repository, synced via cvsup.  If you have multiple machines, you
can even run a cvsup server on one of them, and sync them all from
that.

On older hardware that lacks sufficient disk space for the entire
repo, I use anoncvs, but that's much more annoying. You need to
hack up CVS/Entries manually to add and delete files, for
instance.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Best method to produce patches?

2003-02-10 Thread Trent Nelson
On Sun, Feb 09, 2003 at 04:33:41PM -0600, David Leimbach wrote:
 I am about to try to make some changes to FreeBSD current...
 
 What is the recommend method to use for playing with the source?

I've attached an e-mail from Matt Dillon that gives a very good de-
scription for setting up a FreeBSD development environment.

 Thanks!
 
 Dave Leimbach

Date: Sat, 21 Dec 2002 16:41:23 -0800 (PST)
From: Matthew Dillon [EMAIL PROTECTED]
To: Trent Nelson [EMAIL PROTECTED]
Subject: Re: Trying to chase up an old post.


:Hi Matt,
:
:You posted something to [EMAIL PROTECTED] (or hackers@ possibly)
:just over a year ago describing how you set up your -stable and
:-current environments for doing development.
:
:I've attempted to search for the post, but I'm coming up with false
:hits left right and centre.  Any idea which post I'm referring to,
:or even better, can you point me to a URL where it's been archived?
:
:Much appreciated.
:
:Regards,
:
:Trent.
:
:-- 
:Trent Nelson -- Director, Alcyon Enterprises, Ltd.

I remember making the post, but I don't remember when and I doubt
I could find it in my archives.

Hmm.  This would be another good manual page.  Maybe I will call
it 'developer' or 'development'.  Ok, here we go:

ENVIRONMENT SETUP 

Basically I recommend having at least two machines.  Run -stable
on your main development system.   Create a huge partition called
/FreeBSD.  Mine is 12GB (and currently holds 8G of junk in it,
including portions of NetBSD, OpenBSD, and Linux as well as
FreeBSD).

REASON This way you can export /FreeBSD to any other machines
you have via read-only NFS without exposing sensitive partitions
on your main development machine.

REASON You always want your main development environment to be
on a stable, reliable platform, otherwise you might blow something
up and then not be able to fix it.

Use cvsup (once a night via cron) to keep a local copy of the
FreeBSD CVS tree.

mkdir /FreeBSD/FreeBSD-CVS
ln -s /FreeBSD/FreeBSD-CVS /home/ncvs

cron entry:

20 6 * * *  /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org 
/usr/share/examples/cvsup/cvs-supfile

Then use cvs to checkout and maintain a -stable source tree
and a -current source tree.  I do this:

mkdir /FreeBSD/FreeBSD-4.x
mkdir /FreeBSD/FreeBSD-current

cd /FreeBSD/FreeBSD-4.x
cvs -d /home/ncvs checkout -rRELENG_4 src

cd /FreeBSD/FreeBSD-current
cvs -d /home/ncvs checkout src
cvs -d /home/ncvs checkout ports
cvs -d /home/ncvs checkout doc

REASON Keeping the broken-out source in /FreeBSD allows
you to export it to other machines along with the rest 
of the development environment.

Now create a softlink for /usr/src and /usr/src2.  I
usually point /usr/src at -stable and /usr/src2 at -current:

cd /usr
rm -rf src src2
ln -s /FreeBSD/FreeBSD-4.x/src src
ln -s /FreeBSD/FreeBSD-current/src src

Put /usr/obj in /FreeBSD as well, or give it its own partition
(at least 4GB is recommended).  Example:

mkdir /FreeBSD/obj
cd /usr
rm -rf obj
ln -s /FreeBSD/obj obj

ALTERNATIVE:

(/usr/obj has its own partition)

REASON you are going to want to export /usr/obj via read-only NFS
to your other boxes, which I explain in the BUILDING section.  If
you want to be able to compile the world and kernels on the clients,
rather then only compiling on your main development box, I recommend
making /usr/obj its own partition to make it easier to give each
client its own /usr/obj (for client-side compiling), or mounting
/usr/obj on the client from the main development server via read-only 
NFS.

I usually keep track of ports via CVS and, as you can
see above, a checkedout version can be maintained in
/FreeBSD/FreeBSD-current/ports.   However, in order 
to be able to build ports on other machines you will
need to change the distfiles subdirectory:

cd /usr
rm -rf ports
ln -s /FreeBSD/FreeBSD-current/ports ports

cd /usr/ports   (this pushes into the softlink)
rm -rf distfiles
ln -s /usr/ports.distfiles distfiles

mkdir /usr/ports.distfiles
mkdir /usr/ports.workdir

IN /etc/make.conf add

--
WRKDIRPREFIX=/usr/ports.workdir
--

REASON This allows you to export /usr/ports via a read-only NFS 
mount.  In fact, just exporting /FreeBSD also gives you ports for
free and on your other machines you can simply softlink
/usr/ports to /FreeBSD/FreeBSD-current/ports.  

NOT!!! You may want to choose different directories for distfiles
and workdir, but try to make it consistent 

Re: Best method to produce patches?

2003-02-09 Thread Mike Barcroft
David Leimbach [EMAIL PROTECTED] writes:
 I am about to try to make some changes to FreeBSD current...
 
 Should I begin to use read-only CVS instead of CVSup for this work or 
 is it possible to generate diffs based on CVSup'd sources?
 
 What is the recommend method to use for playing with the source?
 
 I already found a small change in libc that should probably get 
 committed but I want to generate the patch properly for everyone's 
 approval.

Most developers use CVSup to download the repo.

I use the following supfile:
*default host=cvsup10.freebsd.org
*default base=/usr
*default prefix=/work/repo
*default release=cvs
*default delete use-rel-suffix
*default compress
doc-all
ports-all
src-all
www

Then setup an alias for local operations:
alias   lcvscvs -d/work/repo -R

Then:
lcvs checkout src
cd src
[make changes to files]
lcvs diff ~/my.diff

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message