To: Peter Mount <petermount@maidstone.gov.uk>
cc: "'Bruce Momjian'" <pgman@candle.pha.pa.us>,
	Christopher Cain <ccain@mhsoftware.com>, pgsql-interfaces@postgresql.org,
	pgsql-patches@postgresql.org
Subject: Re: [PATCHES] JDBC Patch 
In-reply-to: 
 <1B3D5E532D18D311861A00600865478CF1B3A3@exchange1.nt.maidstone.gov.uk>
References: 
 <1B3D5E532D18D311861A00600865478CF1B3A3@exchange1.nt.maidstone.gov.uk>
Comments: In-reply-to Peter Mount <petermount@maidstone.gov.uk>
	message dated "Tue, 12 Sep 2000 07:56:19 +0100"
Date: Tue, 12 Sep 2000 03:16:20 -0400
Message-ID: <6170.968742980@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Mount <petermount@maidstone.gov.uk> writes:
> Eeek, I've got this in my copy ready to commit. How is CVS going to handle
> this problem?

You'll have to "cvs update" those files and then check that the changes
were merged correctly before you commit.  I believe CVS will not let
you commit a file in which there are changes since your last cvs update.

Although "cvs update" will try to merge the changes from the repository
with your local edits, my experience is that CVS is not too bright about
merging overlapping differences.  I prefer to do the change merge by
hand --- move my modified files someplace else, cvs update to fetch
clean current copies, then edit to bring the files back in sync.  This
process is a bit tedious, but much more reliable than CVS by itself.

Jan Wieck has posted about his preferred method, which IIRC involves
working in a complete separate copy of the source tree, and then
using "diff -c -R" to generate a summary of his changes.  Then he
cvs update's his reference tree and uses "patch" to apply the
diff output to it, followed by hand cleanup of whatever merges patch
couldn't handle.  This is probably a better way if you plan to do
a large pile of changes between syncs with the repository.

			regards, tom lane