Thanks, this follows previous experience where I've had to check out a fresh
set, run diff, and then merge by hand. It's just more tedious with only a
28k connection.
Peter
--
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: petermount@maidstone.gov.uk
WWW: http://www.maidstone.gov.uk
All views expressed within this email are not the views of Maidstone Borough
Council
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, September 12, 2000 8:16 AM
To: Peter Mount
Cc: 'Bruce Momjian'; Christopher Cain; pgsql-interfaces@postgresql.org;
pgsql-patches@postgresql.org
Subject: Re: [PATCHES] JDBC Patch
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
