I seem to have trouble again getting cvs logs for just the 7.0.X branch.
I am running this command from a cvs checkout tree of 7.0.X:

	$ cvs log -d'>2000-06-07 00:00:00 GMT' -rREL7_0_PATCHES

And am seeing entries like below.  Can someone please explain why I am
seeing stuff committed in current?

---------------------------------------------------------------------------

	RCS file: /home/projects/pgsql/cvsroot/pgsql/COPYRIGHT,v
	Working file: COPYRIGHT
	head: 1.5
	branch:
	locks: strict
	access list:
	symbolic names:
		REL7_0_PATCHES: 1.5.0.2
		REL7_0: 1.5
		REL6_5_PATCHES: 1.3.0.4
		REL6_5: 1.3
		REL6_4: 1.3.0.2
		release-6-3: 1.3
		SUPPORT: 1.1.1.1
		PG95-DIST: 1.1.1
	keyword substitution: kv
	total revisions: 6;	selected revisions: 0
	description:
	=============================================================================
	
	RCS file: /home/projects/pgsql/cvsroot/pgsql/GNUmakefile.in,v
	Working file: GNUmakefile.in
	head: 1.14
	branch:
	locks: strict
	access list:
	symbolic names:
	keyword substitution: kv
	total revisions: 14;	selected revisions: 13
	description:
	----------------------------
	revision 1.14
	date: 2000/10/02 22:21:21;  author: petere;  state: Exp;  lines: +4 -2
	"installcheck" doesn't need to depend on "all" since we depend on the user
	to start up a postmaster anyway.
	----------------------------
	revision 1.13
	date: 2000/09/29 17:17:31;  author: petere;  state: Exp;  lines: +3 -1
	New unified regression test driver, test/regress makefile cleanup,
	add "check" and "installcheck" targets, straighten out make variable naming
	of host_os, host_cpu, etc.
	----------------------------
	revision 1.12
	date: 2000/09/21 20:17:41;  author: petere;  state: Exp;  lines: +1 -20
	Replace brain-dead Autoconf macros AC_ARG_{ENABLE,WITH} with something
	that's actually useful, robust, consistent.
	
	Better plan to generate aclocal.m4 as well: use m4 include directives,
	rather than cat.
	...


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 29 Oct 2000 13:12:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
More cvs branch problems
Bruce Momjian writes:

> I seem to have trouble again getting cvs logs for just the 7.0.X branch.
> I am running this command from a cvs checkout tree of 7.0.X:
> 
> 	$ cvs log -d'>2000-06-07 00:00:00 GMT' -rREL7_0_PATCHES
> 
> And am seeing entries like below.  Can someone please explain why I am
> seeing stuff committed in current?

You might want to check out cvs2cl
(http://www.red-bean.com/kfogel/cvs2cl.shtml).  It sems to work nicely and
you get much nicer output because it combines identical log messages in
one multi-file log entry.


-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Thu, 2 Nov 2000 17:00:16 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: More cvs branch problems
Peter Eisentraut wrote:
> 
> Bruce Momjian writes:
> > And am seeing entries like below.  Can someone please explain why I am
> > seeing stuff committed in current?
 
> You might want to check out cvs2cl
> (http://www.red-bean.com/kfogel/cvs2cl.shtml).  It sems to work nicely and
> you get much nicer output because it combines identical log messages in
> one multi-file log entry.

Interesting.

I do have a question -- just how much configuration (and other) changes
occurred to REL7_0_PATCHES (since the logs seem to not be telling the
whole story)?

I say this because I found at least one such change -- REL7_0_PATCHES,
unlike 7.0.2, has an '--enable-syslog' configure switch.  Not a biggie
for me, but I wonder just what else was committed to REL7_0_PATCHES in
the same ilk?

Getting ready to do a mass diff of REL7_0_PATCHES against 7.0.2 release.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Thu, 02 Nov 2000 11:13:21 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: More cvs branch problems
Lamar Owen <lamar.owen@wgcr.org> writes:
> I do have a question -- just how much configuration (and other) changes
> occurred to REL7_0_PATCHES (since the logs seem to not be telling the
> whole story)?
> I say this because I found at least one such change -- REL7_0_PATCHES,
> unlike 7.0.2, has an '--enable-syslog' configure switch.

That's probably the only one, since by back-patching it Marc was
violating one of our standard rules: no new features in dot-releases,
only bug fixes.

To spread blame around fairly ;-), I'm afraid a lot of my own back-patch
log entries just say something like "backpatch FOO" without much detail.
There's more detail in the corresponding log entry in the development
branch, but to get that, you'll need to run cvs2cl without a branch
restriction.  Sorry...

			regards, tom lane

Thu, 02 Nov 2000 12:46:36 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: More cvs branch problems 
Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > I say this because I found at least one such change -- REL7_0_PATCHES,
> > unlike 7.0.2, has an '--enable-syslog' configure switch.
 
> That's probably the only one, since by back-patching it Marc was
> violating one of our standard rules: no new features in dot-releases,
> only bug fixes.

If I may be so bold, this isn't the first time that rule has been
violated, and, it probably won't be the last.  And for many things it
would be an issue -- but this one isn't, if it's the only one, or if
changes are in this ilk.  It's the feature changes that haven't been
beta-tested properly that directly affect operations that worry me --
and those are rare. And the USE_SYSLOG feature itself, even without a
--enable-syslog, has been beta tested pretty thoroughly (and fixed a
couple of times, most notably with the syslog message splitter that,
IIRC, Hiroshi added).  

But I'm not complaining -- the addition of --enable-syslog makes my job
a little easier, as I now don't need to have that particular prepatch to
config.h.in (which patch I loathed making) to enable USE_SYSLOG for the
RPM's.  Of course, making my job easier doesn't necessarily make it
right :-).
 
> To spread blame around fairly ;-), I'm afraid a lot of my own back-patch
> log entries just say something like "backpatch FOO" without much detail.
> There's more detail in the corresponding log entry in the development
> branch, but to get that, you'll need to run cvs2cl without a branch
> restriction.  Sorry...

IOW, the cvs logs (or cvs2cl output) will really have to be gone through
by hand to really get a changelist from 7.0.2 to 7.0.3 instead of a
changelist from 7.0.2 to CURRENT.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Thu, 02 Nov 2000 13:01:44 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: More cvs branch problems
On Thu, 2 Nov 2000, Tom Lane wrote:

> Lamar Owen <lamar.owen@wgcr.org> writes:
> > I do have a question -- just how much configuration (and other) changes
> > occurred to REL7_0_PATCHES (since the logs seem to not be telling the
> > whole story)?
> > I say this because I found at least one such change -- REL7_0_PATCHES,
> > unlike 7.0.2, has an '--enable-syslog' configure switch.
> 
> That's probably the only one, since by back-patching it Marc was
> violating one of our standard rules: no new features in dot-releases,
> only bug fixes.

What new feature?  syslog logging has been there for awhile, all I did was
allow it to be enabled through configure vs having to edit the config.h
file ...



Thu, 2 Nov 2000 20:21:21 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: More cvs branch problems 