Report: removing the inconsistencies in our CVS->git conversion

I've spent much of the weekend examining the discrepancies between our CVS
repository and the tarballs available from our FTP archives, and after
that trying to remove infelicities in the cvs2git output. There are a
couple of remaining oddities that I would classify as probable cvs2git
bugs, but an awful lot of it is inconsistencies in the CVS repository
itself, some of which I can explain and some that I can't. Read on for
many boring details.

One thing that only old-timers will recall is that originally the PG code
base was divided into multiple repositories. There was one for the server
code and one for the client interfaces, and I believe that at the very
beginning much of the documentation was in yet a third place. The oldest
stuff that's now in src/interfaces/ was in the client repository. It
looks to me like when the earliest tarballs were made up, the
subdirectories that were in the client repository were dumped directly
under src/ instead of src/interfaces; that is, the directory layout of
those tarballs does not exactly match the current CVS repository layout.

I also found out that somebody seems to have manually moved the RCS file
for src/backend/commands/version.c into src/backend/commands/_deadcode,
and that a couple of subdirectories apparently were manually renamed
somewhere along the line.

The upshot of all this is that if you want to match the old tarballs to
current CVS contents, you need to make these hacks:

# hacks to make certain old versions diff successfully
if ((-d "postgresql-v$tag/src" and
not -d "postgresql-v$tag/src/interfaces") or
-d "postgres95/src") {
print "moving src/interfaces for $tag\n";
system("mv cvsout/src/interfaces/* cvsout/src") == 0 || die "mv failed: $?";
system("rmdir cvsout/src/interfaces") == 0 || die "rmdir failed: $?";
}
if (-d "postgresql-v$tag/src/pgsql_perl5") {
print "moving perl5 for $tag\n";
system("mv cvsout/src/perl5 cvsout/src/pgsql_perl5") == 0 || die "mv failed: $?";
}
if (-f "postgresql-$tag/src/backend/commands/version.c" or
-f "postgresql-v$tag/src/backend/commands/version.c" or
-f "postgres95/src/backend/commands/version.c") {
print "moving version.c for $tag\n";
system("mv cvsout/src/backend/commands/_deadcode/version.c cvsout/src/backend/commands") == 0 || die "mv failed: $?";
system("rmdir cvsout/src/backend/commands/_deadcode 2>/dev/null");
}
if (-d "postgresql-$tag/src/test/locale/ISO8859-7") {
print "moving ISO8859-7 for $tag\n";
system("mv cvsout/src/test/locale/gr_GR.ISO8859-7 cvsout/src/test/locale/ISO8859-7") == 0 || die "mv failed: $?";
}

Just for the record, these are the versions for which these tests hit:

moving src/interfaces for 1.08
moving version.c for 1.08
moving src/interfaces for 1.09
moving version.c for 1.09
moving src/interfaces for 6.1
moving perl5 for 6.1
moving version.c for 6.1
moving src/interfaces for 6.1.1
moving perl5 for 6.1.1
moving version.c for 6.1.1
moving version.c for 6.2
moving version.c for 6.2.1
moving version.c for 6.3.2
moving ISO8859-7 for 6.5
moving ISO8859-7 for 6.5.1
moving ISO8859-7 for 6.5.2
moving ISO8859-7 for 6.5.3

With those changes, I am able to match all the available archival tarballs
to various places in the CVS history. The exact spots where they match
are detailed in the attached "matches" file. The file also shows the
cvsroot path and CVS module name that was in use at each time; you need
to duplicate that if you want $Header$ lines to match what's in the
tarballs. (I set up symlinks to the base repository on my machine so that
CVS could check out successfully for each of these scenarios.)

There are still a couple of unexplainable discrepancies, though.
In particular, the 1.08 and 1.09 tarballs contain this fix:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpgtcl/Attic/pgtclCmds.c.diff?r1=1.10;r2=1.11
which is odd because it wasn't applied to CVS till months after those
tarballs were made. Even odder, the file timestamp on pgtclCmds.c in
the tarballs agrees with CVS revision 1.2, which is what ought to be in
those tarballs according to CVS. It may be that this fix was made in the
separate client-code repository and not propagated to the core till later;
but that theory doesn't explain the exact timestamp match.

Anyway, the distressing thing about what the "matches" file shows is that
we do not have CVS tags for a lot of the older tarballs. Even worse,
there are a couple of CVS tags that look like they ought to match released
tarballs, but do not: the tags were evidently applied a few commits before
the tarball was actually made. In particular, the tags REL6_5, REL7_1,
and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
lot of faith in some of the other early tags either, because we don't seem
to have an archived tarball to compare them to.

Having completed that comparison, I then moved on to trying to get rid of
the discrepancies in the git conversion; particularly, trying to get rid
of the "manufactured commits". I didn't have much success in that for the
cases where the manufactured commit was caused by a back-branch file
addition. The case I showed before where things cleaned up nicely (for
pg_dump's it.po) depended on the fact that the place where the branch
would naturally sprout off happened to be a "dead" revision on HEAD.
That's not the case anywhere else, so I gave up on the complicated patch
for it.po. The patches I'm using instead just inject a dead ".0" revision
immediately after the branch point, and are pretty small and easy to
verify. I only bothered to do this for the cases where the back-branch
addition happened significantly later than the main-branch addition. If
they were done in a group of related commits with nothing else in between,
I left well enough alone. We still have "manufactured" commits either
way, but they are just cosmetic so I guess we should live with them.

I also found numerous places where we'd been sloppy about placing tags.
That explains some of the weird things cvs2git did. In particular:

* We had the already-known problem that gram.c and some other derived
files had commits made after they should have been dead.

* Bruce had transiently added those files on the WIN32_DEV branch as
well, to general disapproval, and this seemed to also give cvs2git
indigestion. The attached proposed fixup script deals with this by
deleting those revisions altogether. This is a loss of history, but
not one that I care about.

* The HISTORY and INSTALL files have REL7_3_10 tags and should not.
As mentioned earlier, I think this is because they were deleted after the
original placement of that tag, and weren't correctly fixed when the
tag was moved up to branch end a few days later.

* The regression tests files recently added to contrib/xml2 have REL8_0_23
tags. I have no idea how that happened, because they certainly didn't
exist when 8.0.23 was released.

* There are a bunch of files that should have REL7_3_5 tags and lack them.
They are in just a few subdirectories, so probably what happened was that
the "cvs tag" operation was issued in an incomplete checkout tree.

* Similarly, gram.c should have a release-6-3 tag and lacks it.

* There are a bunch of files that have REL7_1 tags when what they should
have are REL7_1_BETA tags. These appear to be exactly the files that were
deleted between the initial placement of the REL7_1 tag and Marc's later
ex-post-facto renaming of the tag to REL7_1_BETA. I'm guessing another
case of "cvs tag" missing files that weren't in the checkout.

* There are a number of files that lack the REL2_0 tag and REL2_0B branch,
though they should have it according to file dates. These appear to be
exactly the files that were in the separate documentation repository at
the time, so that probably tells us the mechanism for missing them.

After fixing all the above items using the attached script, I have what
seems to be a reasonably clean conversion. I still have the three
oddities alluded to over in the "uh-oh" thread, but I'm not sure any of
them should be considered blockers for making the conversion. There are
also some cosmetic issues remaining, like what committer to blame the
various inserted commits on and whether we want to keep partial tags.
But this message is long enough already so I'll get to those issues
separately.

Attached are an updated version of Max's README file about how to perform
the conversion, the repository fixup script needed for that, the Perl
script I used for comparing CVS to tarballs, and the input file for the
Perl script, which shows which CVS tag or checkout date to compare against
each of the available tarballs.

regards, tom lane

On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've spent much of the weekend examining the discrepancies between our CVS
> repository and the tarballs available from our FTP archives, and after
> that trying to remove infelicities in the cvs2git output.  There are a
> couple of remaining oddities that I would classify as probable cvs2git
> bugs, but an awful lot of it is inconsistencies in the CVS repository
> itself, some of which I can explain and some that I can't.  Read on for
> many boring details.

First of all, WOW, and thank you very much for putting in the time to
make this happen.

> With those changes, I am able to match all the available archival tarballs
> to various places in the CVS history.  The exact spots where they match
> are detailed in the attached "matches" file.  The file also shows the

Regrettably, all of your attachments came through as part of the
actual email, both in my GMail and in the archives. I hate
technology.

> Having completed that comparison, I then moved on to trying to get rid of
> the discrepancies in the git conversion; particularly, trying to get rid
> of the "manufactured commits".  I didn't have much success in that for the
> cases where the manufactured commit was caused by a back-branch file
> addition. [...]  We still have "manufactured" commits either
> way, but they are just cosmetic so I guess we should live with them.

I'm not really following what the history looks like here. What are
the contents (git show) of the manufactured commit?

> I also found numerous places where we'd been sloppy about placing tags.
> That explains some of the weird things cvs2git did.  In particular:
>
> * We had the already-known problem that gram.c and some other derived
> files had commits made after they should have been dead.
>
> * Bruce had transiently added those files on the WIN32_DEV branch as
> well, to general disapproval, and this seemed to also give cvs2git
> indigestion.  The attached proposed fixup script deals with this by
> deleting those revisions altogether.  This is a loss of history, but
> not one that I care about.
>
> * The HISTORY and INSTALL files have REL7_3_10 tags and should not.
> As mentioned earlier, I think this is because they were deleted after the
> original placement of that tag, and weren't correctly fixed when the
> tag was moved up to branch end a few days later.
>
> * The regression tests files recently added to contrib/xml2 have REL8_0_23
> tags.  I have no idea how that happened, because they certainly didn't
> exist when 8.0.23 was released.
>
> * There are a bunch of files that should have REL7_3_5 tags and lack them.
> They are in just a few subdirectories, so probably what happened was that
> the "cvs tag" operation was issued in an incomplete checkout tree.
>
> * Similarly, gram.c should have a release-6-3 tag and lacks it.
>
> * There are a bunch of files that have REL7_1 tags when what they should
> have are REL7_1_BETA tags.  These appear to be exactly the files that were
> deleted between the initial placement of the REL7_1 tag and Marc's later
> ex-post-facto renaming of the tag to REL7_1_BETA.  I'm guessing another
> case of "cvs tag" missing files that weren't in the checkout.
>
> * There are a number of files that lack the REL2_0 tag and REL2_0B branch,
> though they should have it according to file dates.  These appear to be
> exactly the files that were in the separate documentation repository at
> the time, so that probably tells us the mechanism for missing them.

I wonder if we should consider fixing some or all of these things on
the master CVS repository. I wouldn't be too eager to inject those
fake .0 commits for fear of breakage, but moving tags to where they
ought to have been all along seems like it might be a good thing to do
independent of git.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Regrettably, all of your attachments came through as part of the
> actual email, both in my GMail and in the archives. I hate
> technology.

Sorry about that. Here's another try with the stuff in a tarball.
This time, I also remembered to include cvs2git.options; although
I think it's the same as Max's original except for

- r'cvsroot/pgsql',
+ r'/cvsroot/pgsql',

I'll address the other points in a bit.

regards, tom lane

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Having completed that comparison, I then moved on to trying to get rid of
>> the discrepancies in the git conversion; particularly, trying to get rid
>> of the "manufactured commits". I didn't have much success in that for the
>> cases where the manufactured commit was caused by a back-branch file
>> addition. [...] We still have "manufactured" commits either
>> way, but they are just cosmetic so I guess we should live with them.

> I'm not really following what the history looks like here. What are
> the contents (git show) of the manufactured commit?

A typical example is

commit 4d2ac8075a93c685dbbe920f4bac23288dd7cf11
Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
Date: Tue Nov 22 18:17:36 2005 +0000

This commit was manufactured by cvs2svn to create branch 'REL7_4_STABLE'.

Cherrypick from master 2005-11-22 18:17:34 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Re-run pgindent, fixing a problem where comment lines after a blank':
src/port/unsetenv.c

diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
new file mode 100644
index 0000000..bdfb3f6
--- /dev/null
+++ b/src/port/unsetenv.c
@@ -0,0 +1,56 @@
+ [ entire contents of unsetenv.c here ]

In the cases where I inserted a dead .0 revision, this is followed by
something like

commit a1bdd263ca8ff657365a97a560f6371f39295efc
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Nov 22 18:17:37 2005 +0000

Mark branch as deleted.

diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
deleted file mode 100644
index bdfb3f6..0000000
--- a/src/port/unsetenv.c
+++ /dev/null
@@ -1,56 +0,0 @@
- [ entire contents of unsetenv.c here too ]

I'm a bit disappointed by the fact that we get either of these. I had
gathered from Max's comments that the dead-revision-at-the-base-of-the-
branch trick is considered standard in newer CVS versions, and so I'd
hoped that cvs2git would understand the construct and not generate
either of these commits. Possibly the hacked-up revisions I inserted
are enough different from the regular kind to confuse it.

>> I also found numerous places where we'd been sloppy about placing tags.

> I wonder if we should consider fixing some or all of these things on
> the master CVS repository. I wouldn't be too eager to inject those
> fake .0 commits for fear of breakage, but moving tags to where they
> ought to have been all along seems like it might be a good thing to do
> independent of git.

Yeah, that's something I was wondering too. Applying these fixes to the
master repository would also reduce the number of things we have to
remember to do during the final conversion. OTOH, there's that risk of
breaking something.

regards, tom lane

On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Having completed that comparison, I then moved on to trying to get rid of
>>> the discrepancies in the git conversion; particularly, trying to get rid
>>> of the "manufactured commits".  I didn't have much success in that for the
>>> cases where the manufactured commit was caused by a back-branch file
>>> addition. [...]  We still have "manufactured" commits either
>>> way, but they are just cosmetic so I guess we should live with them.
>
>> I'm not really following what the history looks like here.  What are
>> the contents (git show) of the manufactured commit?
>
> A typical example is
>
> commit 4d2ac8075a93c685dbbe920f4bac23288dd7cf11
> Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
> Date:   Tue Nov 22 18:17:36 2005 +0000
>
>    This commit was manufactured by cvs2svn to create branch 'REL7_4_STABLE'.
>
>    Cherrypick from master 2005-11-22 18:17:34 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Re-run pgindent, fixing a problem where comment lines after a blank':
>        src/port/unsetenv.c
>
> diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
> new file mode 100644
> index 0000000..bdfb3f6
> --- /dev/null
> +++ b/src/port/unsetenv.c
> @@ -0,0 +1,56 @@
> + [ entire contents of unsetenv.c here ]
>
> In the cases where I inserted a dead .0 revision, this is followed by
> something like
>
> commit a1bdd263ca8ff657365a97a560f6371f39295efc
> Author: Bruce Momjian <bruce(at)momjian(dot)us>
> Date:   Tue Nov 22 18:17:37 2005 +0000
>
>    Mark branch as deleted.

If we have two commits one right after the other that cancel each
other out, we might be able to write them both out of the history
using git-filter-branch. But if Max or Michael can shed any light on
why it's happening, that might lead to a simpler solution.

>>> I also found numerous places where we'd been sloppy about placing tags.
>
>> I wonder if we should consider fixing some or all of these things on
>> the master CVS repository.  I wouldn't be too eager to inject those
>> fake .0 commits for fear of breakage, but moving tags to where they
>> ought to have been all along seems like it might be a good thing to do
>> independent of git.
>
> Yeah, that's something I was wondering too.  Applying these fixes to the
> master repository would also reduce the number of things we have to
> remember to do during the final conversion.  OTOH, there's that risk of
> breaking something.

Hand-written patches that apply directly to the RCS files seem like
they'd be a risk for breakage, but I don't see why moving tags around
would be all that dangerous, especially in cases where you can do it
by running 'cvs' itself rather than 'rcs'. That should just be
routine stuff, no?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> I wonder if we should consider fixing some or all of these things on
>>> the master CVS repository. I wouldn't be too eager to inject those
>>> fake .0 commits for fear of breakage, but moving tags to where they
>>> ought to have been all along seems like it might be a good thing to do
>>> independent of git.

>> Yeah, that's something I was wondering too. Applying these fixes to the
>> master repository would also reduce the number of things we have to
>> remember to do during the final conversion. OTOH, there's that risk of
>> breaking something.

> Hand-written patches that apply directly to the RCS files seem like
> they'd be a risk for breakage, but I don't see why moving tags around
> would be all that dangerous, especially in cases where you can do it
> by running 'cvs' itself rather than 'rcs'. That should just be
> routine stuff, no?

Hrm, well, keep in mind that most of these problems were *created* by
careless use of "cvs tag". At the moment I'm leaning towards the idea
that we should leave the CVS repository as it is, rather than take any
risk of making things worse.

regards, tom lane

On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> I wonder if we should consider fixing some or all of these things on
>>>> the master CVS repository.  I wouldn't be too eager to inject those
>>>> fake .0 commits for fear of breakage, but moving tags to where they
>>>> ought to have been all along seems like it might be a good thing to do
>>>> independent of git.
>
>>> Yeah, that's something I was wondering too.  Applying these fixes to the
>>> master repository would also reduce the number of things we have to
>>> remember to do during the final conversion.  OTOH, there's that risk of
>>> breaking something.
>
>> Hand-written patches that apply directly to the RCS files seem like
>> they'd be a risk for breakage, but I don't see why moving tags around
>> would be all that dangerous, especially in cases where you can do it
>> by running 'cvs' itself rather than 'rcs'.  That should just be
>> routine stuff, no?
>
> Hrm, well, keep in mind that most of these problems were *created* by
> careless use of "cvs tag".  At the moment I'm leaning towards the idea
> that we should leave the CVS repository as it is, rather than take any
> risk of making things worse.

I think that I have never, and am never likely ever to, hear anyone
describe you as careless. I feel pretty much 100% safe having you
retag those releases to match the tarballs.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

I wrote:
> I'm a bit disappointed by the fact that we get either of these. I had
> gathered from Max's comments that the dead-revision-at-the-base-of-the-
> branch trick is considered standard in newer CVS versions, and so I'd
> hoped that cvs2git would understand the construct and not generate
> either of these commits. Possibly the hacked-up revisions I inserted
> are enough different from the regular kind to confuse it.

Hah: a bit of digging in the cvs2svn sources found this:

def _is_unneeded_initial_branch_delete(self, lod_items, metadata_db):
"""Return True iff the initial revision in LOD_ITEMS can be deleted."""

if not lod_items.cvs_revisions:
return False

cvs_revision = lod_items.cvs_revisions[0]

if cvs_revision.ntdbr:
return False

if not isinstance(cvs_revision, CVSRevisionAbsent):
return False

if cvs_revision.branch_ids:
return False

log_msg = metadata_db[cvs_revision.metadata_id].log_msg
return bool(re.match(
r'file .* was added on branch .* on '
r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
'\n$',
log_msg,
))

So it looks like I have to make the dead revisions' log messages match
that regexp. Off to make another try.

regards, tom lane

I wrote:
> return bool(re.match(
> r'file .* was added on branch .* on '
> r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
> '\n$',
> log_msg,
> ))

> So it looks like I have to make the dead revisions' log messages match
> that regexp. Off to make another try.

It works! Now I don't see either the manufactured commits or the
patched-in deletions.

I had not previously bothered to patch the places where a file was added
on the branch immediately after being added on the main, but now it
seems worth doing. That will get us down to a *very* small number of
manufactured commits in the final version.

regards, tom lane

On Mon, Sep 13, 2010 at 21:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>>     return bool(re.match(
>>         r'file .* was added on branch .* on '
>>         r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
>>         '\n$',
>>         log_msg,
>>         ))
>
>> So it looks like I have to make the dead revisions' log messages match
>> that regexp.  Off to make another try.
>
> It works!  Now I don't see either the manufactured commits or the
> patched-in deletions.
>
> I had not previously bothered to patch the places where a file was added
> on the branch immediately after being added on the main, but now it
> seems worth doing.  That will get us down to a *very* small number of
> manufactured commits in the final version.

That's awesome!

Thanks so much for doing this. I've come to realize I know far too
little about *cvs* to work on those things myself :S

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Tom Lane wrote:
> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
> lot of faith in some of the other early tags either, because we don't seem
> to have an archived tarball to compare them to.

I believe I have those on a CDROM here.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
>> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
>> lot of faith in some of the other early tags either, because we don't seem
>> to have an archived tarball to compare them to.

> I believe I have those on a CDROM here.

If you can recover any of the releases that aren't on ftp-archive,
please send me copies.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
> >> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
> >> lot of faith in some of the other early tags either, because we don't seem
> >> to have an archived tarball to compare them to.
>
> > I believe I have those on a CDROM here.
>
> If you can recover any of the releases that aren't on ftp-archive,
> please send me copies.

Sure. I have a copy of our ftp site /pub as of 6.3 and have put it
online:

http://momjian.us/expire/pgsql_ftp_6.3/

Unfortunately I don't see anything there that isn't already here:

ftp://ftp-archives.postgresql.org/pub/source/

but let me know if you find something new.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> If you can recover any of the releases that aren't on ftp-archive,
>> please send me copies.

> Sure. I have a copy of our ftp site /pub as of 6.3 and have put it
> online:
> http://momjian.us/expire/pgsql_ftp_6.3/

> Unfortunately I don't see anything there that isn't already here:
> ftp://ftp-archives.postgresql.org/pub/source/

Well, you seem to have 6.0 and 6.3 initial releases, which I didn't
have before, so thanks for that. But you're failing to realize that
you have unadulterated historical gold here:

http://momjian.us/expire/pgsql_ftp_6.3/majordomo/

What that looks like to me is an archive of our mailing lists from 1996
to 1998. The material at archives.postgresql.org doesn't go back that
far, at least not for all the lists. Is anybody up for merging that
traffic into the main archives?

regards, tom lane

I wrote:
> I had not previously bothered to patch the places where a file was added
> on the branch immediately after being added on the main, but now it
> seems worth doing. That will get us down to a *very* small number of
> manufactured commits in the final version.

Attached is an updated repository.fixups script that inserts dead
revisions in every case where a new file was back-patched into an
existing branch. With that, we are down to a total of nine manufactured
commits, to wit:

* Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
Release-1-6-0. I think we agreed that we can just drop these tags and
allow their manufactured commits to be garbage-collected.

* Two that create the tags Release_2_0 and Release_2_0_0. I think these
probably represent a cvs2git bug, as there is no apparent reason why it
didn't just apply the tags to the immediately preceding mainline commits
instead. In any case, we can get rid of them by moving the tags to the
appropriate commits manually.

* One that creates the branch REL2_0B. This is caused by a known,
longstanding cvs2git deficiency: it fails to pick the optimal place
to branch from when file deletions are involved. We're just going to
have to live with that, I think; it's a pretty minor infelicity anyway.

* One that creates the partial branch ecpg_big_bison. I think we have
to live with this too. I don't want to drop the branch altogether,
as that would represent a loss of development history. The only other
alternative I can think of is to try to convert it into a full branch,
but I'm unsure what the implications would be of that.

* And lastly, there's a weird manufactured commit that adds a passel of
files on REL7_3_STABLE branch, only to have them deleted again by the
following real commit. This is a result of the fact that the branch
point was moved long after creation, as discussed here:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00127.php
We could maybe try to get rid of both the manufactured commit and
the deletion commit, but I'm inclined not to. The underlying history
is really as dirty as this commit makes it look.

The long and the short of it is that I'm now satisfied with the git
conversion. There is still the issue of adding/adjusting release tags
for ancient releases, but the lack of those is surely not the
conversion's fault.

regards, tom lane

PS: This attachment is text/x-patch instead of text/plain ... does
it come through as an attachment for you, Robert?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> PS: This attachment is text/x-patch instead of text/plain ... does
> it come through as an attachment for you, Robert?

From my MUA, I can say that it's not so much a problem of MIME type than
the Content-Disposition, yours are always inline.

http://www.gnus.org/manual/emacs-mime_11.html#SEC11
http://en.wikipedia.org/wiki/MIME#Content-Disposition

Regards,
--
dim

On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
> Release-1-6-0.  I think we agreed that we can just drop these tags and
> allow their manufactured commits to be garbage-collected.

+1.

> * Two that create the tags Release_2_0 and Release_2_0_0.  I think these
> probably represent a cvs2git bug, as there is no apparent reason why it
> didn't just apply the tags to the immediately preceding mainline commits
> instead.  In any case, we can get rid of them by moving the tags to the
> appropriate commits manually.

+1.

> * One that creates the branch REL2_0B.  This is caused by a known,
> longstanding cvs2git deficiency: it fails to pick the optimal place
> to branch from when file deletions are involved.  We're just going to
> have to live with that, I think; it's a pretty minor infelicity anyway.

Fine with me.

> * One that creates the partial branch ecpg_big_bison.  I think we have
> to live with this too.  I don't want to drop the branch altogether,
> as that would represent a loss of development history.  The only other
> alternative I can think of is to try to convert it into a full branch,
> but I'm unsure what the implications would be of that.

I doubt there's a clean way to do that. I am not sure there's much
point in moving the tag over to git - anyone wanting to do something
useful with it will need to use CVS anyway, won't they?

> * And lastly, there's a weird manufactured commit that adds a passel of
> files on REL7_3_STABLE branch, only to have them deleted again by the
> following real commit.  This is a result of the fact that the branch
> point was moved long after creation, as discussed here:
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00127.php
> We could maybe try to get rid of both the manufactured commit and
> the deletion commit, but I'm inclined not to.  The underlying history
> is really as dirty as this commit makes it look.

OK.

> The long and the short of it is that I'm now satisfied with the git
> conversion.  There is still the issue of adding/adjusting release tags
> for ancient releases, but the lack of those is surely not the
> conversion's fault.

Great.

> PS: This attachment is text/x-patch instead of text/plain ... does
> it come through as an attachment for you, Robert?

Yep, thanks. I'd like to have Magnus run a test conversion with all
the latest and greatest stuff and throw it up somewhere so we can all
poke at it.

Incidentally, with respect to timing, do we want to press on with this
conversion now or wait until after the CommitFest is done?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Incidentally, with respect to timing, do we want to press on with this
> conversion now or wait until after the CommitFest is done?

I'd kind of like to do it before we start the commitfest. These
repository patches will go stale if we wait too long, and a month
is probably too long. In any case I'd rather get it done while all
the information is fresh in mind.

The main schedule constraint I can see at the moment is that 9.0 wrap is
scheduled for Thursday, and I think we probably don't want to do it
before the wrap.

Another issue is that we need a chunk of Magnus' time to shepherd the
conversion, and I don't know what his availability is.

regards, tom lane

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * One that creates the partial branch ecpg_big_bison. I think we have
>> to live with this too. I don't want to drop the branch altogether,
>> as that would represent a loss of development history. The only other
>> alternative I can think of is to try to convert it into a full branch,
>> but I'm unsure what the implications would be of that.

> I doubt there's a clean way to do that. I am not sure there's much
> point in moving the tag over to git - anyone wanting to do something
> useful with it will need to use CVS anyway, won't they?

Well ... I guess the other attitude we could take is that that was a
private development branch of Michael's. If we'd been working in git
at the time, that branch would never have been seen outside his personal
repository, most likely. The changes did eventually get merged back to
HEAD, so we'd not be losing anything critical if we just dropped the
branch altogether. Anybody else have an opinion on what to do with it?

regards, tom lane

Excerpts from Dimitri Fontaine's message of mar sep 14 11:10:50 -0400 2010:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > PS: This attachment is text/x-patch instead of text/plain ... does
> > it come through as an attachment for you, Robert?
>
> From my MUA, I can say that it's not so much a problem of MIME type than
> the Content-Disposition, yours are always inline.

Hmm, I see it as a separate attachment in this case. The original mail
was indeed "collapsed" in that all the text attachments looked like a
single text stream.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Sep 14, 2010 at 12:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> * One that creates the partial branch ecpg_big_bison.  I think we have
>>> to live with this too.  I don't want to drop the branch altogether,
>>> as that would represent a loss of development history.  The only other
>>> alternative I can think of is to try to convert it into a full branch,
>>> but I'm unsure what the implications would be of that.
>
>> I doubt there's a clean way to do that.  I am not sure there's much
>> point in moving the tag over to git - anyone wanting to do something
>> useful with it will need to use CVS anyway, won't they?
>
> Well ... I guess the other attitude we could take is that that was a
> private development branch of Michael's.  If we'd been working in git
> at the time, that branch would never have been seen outside his personal
> repository, most likely.  The changes did eventually get merged back to
> HEAD, so we'd not be losing anything critical if we just dropped the
> branch altogether.  Anybody else have an opinion on what to do with it?

We're not planning to delete the CVS repository, are we?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> We're not planning to delete the CVS repository, are we?

Not in the short term, but I'd like to think that the git repository
will contain everything of conceivable interest.

regards, tom lane

On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> We're not planning to delete the CVS repository, are we?
>
> Not in the short term, but I'd like to think that the git repository
> will contain everything of conceivable interest.

Hmm, OK. That's never really been one of my goals. :-)

I want a good, clean, complete history in git, but ancient partial
branches are below my threshold for caring. But if you feel it's
useful, we can keep the tag - I don't care enough to argue about it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> We're not planning to delete the CVS repository, are we?
>>
>> Not in the short term, but I'd like to think that the git repository
>> will contain everything of conceivable interest.

> Hmm, OK. That's never really been one of my goals. :-)

I will confess to moving the goal posts a bit ;-). If we didn't have
such a near-perfect conversion, I would be willing to throw stuff
overboard on the grounds that people could go back to the CVS repository
if they cared. But we are at a point now where it's very hard to
conceive of a reason for needing to do that. So I don't want to
arbitrarily create reasons.

> I want a good, clean, complete history in git, but ancient partial
> branches are below my threshold for caring. But if you feel it's
> useful, we can keep the tag - I don't care enough to argue about it.

... but having said that, I'm not sure that the ecpg_big_bison branch
should be considered part of the core project history. You could
certainly argue that it wouldn't be there anyway if we'd had better
tools.

Again, I'd be interested to hear some other people's opinions.

regards, tom lane

Excerpts from Tom Lane's message of mar sep 14 12:45:28 -0400 2010:

> > I want a good, clean, complete history in git, but ancient partial
> > branches are below my threshold for caring. But if you feel it's
> > useful, we can keep the tag - I don't care enough to argue about it.
>
> ... but having said that, I'm not sure that the ecpg_big_bison branch
> should be considered part of the core project history. You could
> certainly argue that it wouldn't be there anyway if we'd had better
> tools.
>
> Again, I'd be interested to hear some other people's opinions.

I think there's hardly much of interest in that branch, so it doesn't
make sense to waste too much effort on it. However, why would we delete
it? Just keep it with the manufactured tag and all -- so it is there,
even if the history is not all that clean. This _is_ an option, right?

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I think there's hardly much of interest in that branch, so it doesn't
> make sense to waste too much effort on it. However, why would we delete
> it? Just keep it with the manufactured tag and all -- so it is there,
> even if the history is not all that clean. This _is_ an option, right?

That was pretty much my default position; I was just wondering if there
was a consensus to do something else.

regards, tom lane

On Tue, Sep 14, 2010 at 12:01:18PM -0400, Tom Lane wrote:
> Well ... I guess the other attitude we could take is that that was a
> private development branch of Michael's. If we'd been working in git

Actually it wasn't. This branch was created when ecpg grew too big for the
released version of bison. We had to use a development snapshot of bison to
even compile ecpg back then and didn't want to put the ecpg changes into the
main branch because this would have prevented most people from compiling PG. At
least that's what I still remember.

As far as converting this branch to git, I'd say forget about it. All changes
to the parser went into CVS HEAD as soon as a suitable bison version was
released.

Michael

--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Attached is an updated repository.fixups script that inserts dead
> revisions in every case where a new file was back-patched into an
> existing branch.  With that, we are down to a total of nine manufactured
> commits, to wit:
> [details]

Magnus posted an updated conversion this morning.

http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary

Evidently, however, he didn't do the same things you did, because
there are DEFINITELY more than 9 manufactured commits in this one.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Magnus posted an updated conversion this morning.

> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary

> Evidently, however, he didn't do the same things you did, because
> there are DEFINITELY more than 9 manufactured commits in this one.

Um ... I just did
git clone git://git.postgresql.org/git/postgresql-migration.git
and I only see nine. It's got some *other* problems though; compared
to a conversion I just finished locally, it's missing a whole lot of
history for some of the old jdbc files.

Is there any possibility that "git clone" isn't very trustworthy?
It's a bit scary that we don't see identical views of this repository.

regards, tom lane

On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Magnus posted an updated conversion this morning.
>
>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>
>> Evidently, however, he didn't do the same things you did, because
>> there are DEFINITELY more than 9 manufactured commits in this one.
>
> Um ... I just did
>        git clone git://git.postgresql.org/git/postgresql-migration.git
> and I only see nine.  It's got some *other* problems though; compared
> to a conversion I just finished locally, it's missing a whole lot of
> history for some of the old jdbc files.
>
> Is there any possibility that "git clone" isn't very trustworthy?
> It's a bit scary that we don't see identical views of this repository.

*scratches head*

I did a git-fetch into an existing copy of the old contents of that
repository, rather than a fresh clone. Let me nuke it and start over.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On 09/17/2010 11:39 AM, Tom Lane wrote:
> Is there any possibility that "git clone" isn't very trustworthy?
> It's a bit scary that we don't see identical views of this repository.

I should have thought that very unlikely.

cheers

andrew

On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Magnus posted an updated conversion this morning.
>>
>>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>>
>>> Evidently, however, he didn't do the same things you did, because
>>> there are DEFINITELY more than 9 manufactured commits in this one.
>>
>> Um ... I just did
>>        git clone git://git.postgresql.org/git/postgresql-migration.git
>> and I only see nine.  It's got some *other* problems though; compared
>> to a conversion I just finished locally, it's missing a whole lot of
>> history for some of the old jdbc files.
>>
>> Is there any possibility that "git clone" isn't very trustworthy?
>> It's a bit scary that we don't see identical views of this repository.
>
> *scratches head*
>
> I did a git-fetch into an existing copy of the old contents of that
> repository, rather than a fresh clone.  Let me nuke it and start over.

OK, the fresh clone does in fact show just 9 manufactured commits.
Sorry, I must not have cleaned out the old state properly.

What's the problem with the old JDBC files?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> and I only see nine. It's got some *other* problems though; compared
>>> to a conversion I just finished locally, it's missing a whole lot of
>>> history for some of the old jdbc files.

> What's the problem with the old JDBC files?

This is what I sent to Magnus off-list:

There seems to be something wrong with this :-(. I pulled this down
and compared the output of "git log --all --source --name-status"
to what I got from a fresh conversion of my own. There seems to be
a substantial loss of history around some of the jdbc files. See
attached diffs from my log to yours.

regards, tom lane

*** revhist.git17 Fri Sep 17 10:44:50 2010
--- revhist.gitmha Fri Sep 17 11:24:03 2010
***************
*** 236673,236679 ****

From Donald Fraser.

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java

--- 236673,236678 ----
***************
*** 249776,249786 ****
jdbc/org/postgresql/test/jdbc2/ServerCursorTest.java

M src/interfaces/jdbc/org/postgresql/Driver.java.in
- M src/interfaces/jdbc/org/postgresql/core/BaseResultSet.java
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
- M src/interfaces/jdbc/org/postgresql/core/Field.java
- M src/interfaces/jdbc/org/postgresql/core/PGStream.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
--- 249775,249780 ----
***************
*** 254896,254902 ****

Per report from Hans Nather.

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/test/jdbc2/Jdbc2TestSuite.java
A src/interfaces/jdbc/org/postgresql/test/jdbc2/NotifyTest.java
--- 254890,254895 ----
***************
*** 256307,256321 ****
D src/interfaces/jdbc/org/postgresql/PGNotification.java
D src/interfaces/jdbc/org/postgresql/PGRefCursorResultSet.java
D src/interfaces/jdbc/org/postgresql/PGStatement.java
- D src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
- D src/interfaces/jdbc/org/postgresql/core/BaseResultSet.java
- D src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
- D src/interfaces/jdbc/org/postgresql/core/Encoding.java
- D src/interfaces/jdbc/org/postgresql/core/Field.java
- D src/interfaces/jdbc/org/postgresql/core/Notification.java
- D src/interfaces/jdbc/org/postgresql/core/PGStream.java
- D src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- D src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
D src/interfaces/jdbc/org/postgresql/errors.properties
D src/interfaces/jdbc/org/postgresql/errors_de.properties
D src/interfaces/jdbc/org/postgresql/errors_fr.properties
--- 256300,256305 ----
***************
*** 261723,261729 ****
M src/interfaces/jdbc/example/corba/StockServer.java
M src/interfaces/jdbc/example/corba/stock.idl
M src/interfaces/jdbc/example/corba/stock.sql
- M src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
M src/interfaces/jdbc/org/postgresql/test/jdbc2/BlobTest.java
M src/interfaces/jdbc/org/postgresql/test/jdbc2/ConnectionTest.java
M src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
--- 261707,261712 ----
***************
*** 262635,262648 ****
M src/interfaces/jdbc/org/postgresql/PGNotification.java
M src/interfaces/jdbc/org/postgresql/PGRefCursorResultSet.java
M src/interfaces/jdbc/org/postgresql/PGStatement.java
- M src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
- M src/interfaces/jdbc/org/postgresql/core/BaseResultSet.java
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/Field.java
- M src/interfaces/jdbc/org/postgresql/core/Notification.java
- M src/interfaces/jdbc/org/postgresql/core/PGStream.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/errors_de.properties
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/fastpath/FastpathArg.java
--- 262618,262623 ----
***************
*** 266110,266117 ****

Patches from Oliver Jowett to fix CursorFetchTest, 7.4 now does not automatically delete cursors

- M src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
--- 266085,266090 ----
***************
*** 270417,270434 ****

M src/backend/rewrite/rewriteDefine.c

! commit e8839c2b6c00bac6d8119ec0cc27a5e77169c8a0 refs/tags/REL7_4_BETA4
! Author: Barry Lind <barry(at)xythos(dot)com>
! Date: Wed Sep 17 08:21:36 2003 +0000
!
! Applied patch to jdbc from Kim Ho at RedHat, fixing improper handling of empty queries under the V3 protocol
!
! Modified Files:
! jdbc/org/postgresql/core/QueryExecutor.java
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
!
! commit c020d67bc692498520702e8b0734894558d47f70 refs/tags/REL7_4_BETA4
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Wed Sep 17 07:00:24 2003 +0000

--- 270390,270396 ----

M src/backend/rewrite/rewriteDefine.c

! commit 245f6d3d963c59394b08dba31493d9a4374eec3a refs/tags/REL7_4_BETA4
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Wed Sep 17 07:00:24 2003 +0000

***************
*** 270976,270982 ****
jdbc/org/postgresql/util/PSQLState.java

M src/interfaces/jdbc/org/postgresql/Driver.java.in
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/geometric/PGbox.java
M src/interfaces/jdbc/org/postgresql/geometric/PGcircle.java
--- 270938,270943 ----
***************
*** 271667,271673 ****
jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
jdbc/org/postgresql/util/PSQLState.java

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
--- 271628,271633 ----
***************
*** 271821,271829 ****
jdbc/org/postgresql/util/PSQLException.java

M src/interfaces/jdbc/org/postgresql/Driver.java.in
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/PGStream.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
--- 271781,271786 ----
***************
*** 272303,272309 ****
M src/interfaces/ecpg/test/test1.pgc
M src/interfaces/ecpg/test/test_thread.pgc
M src/interfaces/jdbc/build.xml
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/errors_de.properties
M src/interfaces/jdbc/org/postgresql/errors_it.properties
--- 272260,272265 ----
***************
*** 273562,273568 ****
older version of the driver exists in the classpath when trying to build.

M src/interfaces/jdbc/build.xml
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/errors_de.properties
M src/interfaces/jdbc/org/postgresql/errors_it.properties
--- 273518,273523 ----
***************
*** 274536,274545 ****
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/util/PSQLException.java

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/util/PSQLException.java

! commit d7c609f7c4de9cdab1d2bd92964273d4cb34067f refs/heads/WIN32_DEV
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Mon Aug 11 21:12:00 2003 +0000

--- 274491,274499 ----
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/util/PSQLException.java

M src/interfaces/jdbc/org/postgresql/util/PSQLException.java

! commit 6684a3e6a4f2f12052e53ced276a963e4cc150ad refs/remotes/origin/WIN32_DEV
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Mon Aug 11 21:12:00 2003 +0000

***************
*** 274563,274572 ****
jdbc/build.xml jdbc/org/postgresql/core/BaseStatement.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java

- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java

! commit 88381ade63de931c84f53dc873c986d40b8c8b61 refs/heads/WIN32_DEV
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Mon Aug 11 20:46:47 2003 +0000

--- 274517,274525 ----
jdbc/build.xml jdbc/org/postgresql/core/BaseStatement.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java

M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java

! commit cf40c6759694f21bd3bdda9f8ffc9753b159ff72 refs/remotes/origin/WIN32_DEV
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Mon Aug 11 20:46:47 2003 +0000

***************
*** 284744,284755 ****
jdbc/org/postgresql/test/jdbc3/Jdbc3TestSuite.java

M src/interfaces/jdbc/org/postgresql/PGConnection.java
- M src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/Field.java
- M src/interfaces/jdbc/org/postgresql/core/PGStream.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- M src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/fastpath/FastpathArg.java
--- 284697,284702 ----
***************
*** 286670,286680 ****
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

! commit d9fd7d12f6c08f1502e8d57d222797e86198b1a6 refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue May 6 23:34:56 2003 +0000

--- 286617,286625 ----
jdbc/org/postgresql/core/QueryExecutor.java
jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

M src/interfaces/jdbc/org/postgresql/jdbc3/AbstractJdbc3Connection.java

! commit 5cdb62cf6e569c6151ad2b96bb562a75528d699c refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue May 6 23:34:56 2003 +0000

***************
*** 287095,287101 ****
jdbc/org/postgresql/test/jdbc2/RefCursorTest.java

A src/interfaces/jdbc/org/postgresql/PGRefCursorResultSet.java
- M src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
M src/interfaces/jdbc/org/postgresql/jdbc1/Jdbc1CallableStatement.java
--- 287040,287045 ----
***************
*** 288440,288449 ****
jdbc/org/postgresql/core/BaseConnection.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

- M src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

! commit e3859d1ad982880a0d1cc57e4fd5e2b598634fc6 refs/tags/REL7_2_5
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Apr 13 04:07:43 2003 +0000

--- 288384,288392 ----
jdbc/org/postgresql/core/BaseConnection.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

! commit 948072686bbbda38f77130e1e9582c73022dca09 refs/tags/REL7_2_5
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Apr 13 04:07:43 2003 +0000

***************
*** 291990,291996 ****
jdbc/org/postgresql/jdbc2/Array.java
jdbc/org/postgresql/util/PSQLException.java

- M src/interfaces/jdbc/org/postgresql/core/BaseResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
M src/interfaces/jdbc/org/postgresql/util/PSQLException.java
--- 291933,291938 ----
***************
*** 292130,292144 ****
M src/interfaces/jdbc/org/postgresql/PGNotification.java
M src/interfaces/jdbc/org/postgresql/PGStatement.java
D src/interfaces/jdbc/org/postgresql/PG_Stream.java
- A src/interfaces/jdbc/org/postgresql/core/BaseConnection.java
- A src/interfaces/jdbc/org/postgresql/core/BaseResultSet.java
- A src/interfaces/jdbc/org/postgresql/core/BaseStatement.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- A src/interfaces/jdbc/org/postgresql/core/Field.java
- M src/interfaces/jdbc/org/postgresql/core/Notification.java
- A src/interfaces/jdbc/org/postgresql/core/PGStream.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- M src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/fastpath/FastpathArg.java
M src/interfaces/jdbc/org/postgresql/geometric/PGbox.java
--- 292072,292077 ----
***************
*** 294429,294435 ****
jdbc/org/postgresql/core/Encoding.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java

- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java

--- 294362,294367 ----
***************
*** 294446,294452 ****
jdbc/org/postgresql/core/Encoding.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

--- 294378,294383 ----
***************
*** 294766,294788 ****
M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml

! commit 65b4214d06796a8e56c850a57ed74440ae4dabca refs/tags/REL7_3_4
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Tue Feb 4 11:16:00 2003 +0000
!
! Fix for rollback SQLException from Kris Jurka
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
!
! commit 985e551b486647a16c880c01e41cabd37855ecb8 refs/tags/REL7_4_BETA1
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Tue Feb 4 11:01:52 2003 +0000
!
! Applied Kris Jurkas patch to fix rollback and SQLException
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
!
! commit d23fd9572b4cd6bfea3f74067a2d631c20fda886 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Tue Feb 4 10:44:37 2003 +0000

--- 294697,294703 ----
M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml

! commit e1cc52e02ce48b73f0995cfb929723751bb2a612 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Tue Feb 4 10:44:37 2003 +0000

***************
*** 294808,294814 ****
so that rows can be fetched incrementally. This is enabled by using
setFetchSize()

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
--- 294723,294728 ----
***************
*** 302664,302671 ****
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
--- 302578,302583 ----
***************
*** 302686,302693 ****
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
--- 302598,302603 ----
***************
*** 304365,304372 ****
D contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
D contrib/retep/uk/org/retep/util/proped/Main.java
D contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
D contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 304275,304280 ----
***************
*** 304388,304404 ****
D src/interfaces/jdbc/utils/changelog.pl
D src/test/regress/expected/geometry-bsdi-precision.out

! commit 7001c399bb5957ca9b7a3412128ae8e38829ed65 refs/tags/REL7_3_2
! Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
Date: Mon Nov 4 17:14:30 2002 +0000

! This commit was manufactured by cvs2svn to create branch 'REL7_3_STABLE'.

Sprout from master 2002-11-04 17:14:29 UTC Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 'Remove extraneous semicolons after routine bodies. These don't bother'
Cherrypick from master 2002-09-04 07:23:04 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Brand 7.3. Ready for beta!':
contrib/xml/README
contrib/retep/uk/org/retep/xml/test/XMLExport.java
contrib/xml/pgxml.source
contrib/retep/Implementation
contrib/retep/Makefile
contrib/retep/README
--- 304296,304313 ----
D src/interfaces/jdbc/utils/changelog.pl
D src/test/regress/expected/geometry-bsdi-precision.out

! commit 32c0b8b61586afd904cf50d1b5cfd818b77d103b refs/tags/REL7_3_2
! Author: Git to CVS conversion script <webmaster(at)postgresql(dot)org>
Date: Mon Nov 4 17:14:30 2002 +0000

! This commit was manufactured by cvs2git to create branch 'REL7_3_STABLE'.

Sprout from master 2002-11-04 17:14:29 UTC Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 'Remove extraneous semicolons after routine bodies. These don't bother'
Cherrypick from master 2002-09-04 07:23:04 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Brand 7.3. Ready for beta!':
contrib/xml/README
contrib/retep/uk/org/retep/xml/test/XMLExport.java
contrib/xml/pgxml.source
+ contrib/retep/CHANGELOG
contrib/retep/Implementation
contrib/retep/Makefile
contrib/retep/README
***************
*** 304406,304419 ****
contrib/retep/retep.jpx
contrib/retep/data/cds.dtd
contrib/retep/data/cds.xml
- contrib/retep/uk/org/retep/tools.properties
- contrib/retep/uk/org/retep/dtu/DCollection.java
- contrib/retep/uk/org/retep/dtu/DConstants.java
contrib/xml/pgxml_dom.source
contrib/retep/uk/org/retep/dtu/DElement.java
contrib/retep/uk/org/retep/dtu/DEnvironment.java
contrib/retep/uk/org/retep/dtu/DModule.java
- contrib/retep/uk/org/retep/dtu/DModuleXML.java
contrib/retep/uk/org/retep/dtu/DNode.java
contrib/retep/uk/org/retep/dtu/DProcessor.java
contrib/retep/uk/org/retep/dtu/DTransform.java
--- 304315,304325 ----
contrib/retep/retep.jpx
contrib/retep/data/cds.dtd
contrib/retep/data/cds.xml
contrib/xml/pgxml_dom.source
+ contrib/retep/uk/org/retep/dtu/DConstants.java
contrib/retep/uk/org/retep/dtu/DElement.java
contrib/retep/uk/org/retep/dtu/DEnvironment.java
contrib/retep/uk/org/retep/dtu/DModule.java
contrib/retep/uk/org/retep/dtu/DNode.java
contrib/retep/uk/org/retep/dtu/DProcessor.java
contrib/retep/uk/org/retep/dtu/DTransform.java
***************
*** 304433,304455 ****
contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
contrib/retep/uk/org/retep/util/proped/Main.java
contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
contrib/retep/uk/org/retep/xml/parser/TagListener.java
doc/src/sgml/libpgeasy.sgml
doc/src/sgml/odbc.sgml
doc/src/sgml/recovery.sgml
- src/test/regress/expected/geometry-bsdi-precision.out
- contrib/retep/uk/org/retep/xml/parser/TagHandler.java
doc/src/sgml/version.sgml
doc/src/sgml/y2k.sgml
- src/interfaces/jdbc/utils/CheckVersion.java
src/interfaces/jdbc/utils/buildDriver
src/interfaces/jdbc/utils/changelog.pl
src/interfaces/jdbc/Implementation
! contrib/retep/CHANGELOG
src/interfaces/jdbc/CHANGELOG
src/interfaces/jdbc/jdbc.jpx

--- 304339,304361 ----
contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
contrib/retep/uk/org/retep/util/proped/Main.java
contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
+ contrib/retep/uk/org/retep/xml/parser/TagHandler.java
contrib/retep/uk/org/retep/xml/parser/TagListener.java
doc/src/sgml/libpgeasy.sgml
+ src/test/regress/expected/geometry-bsdi-precision.out
doc/src/sgml/odbc.sgml
doc/src/sgml/recovery.sgml
doc/src/sgml/version.sgml
doc/src/sgml/y2k.sgml
src/interfaces/jdbc/utils/buildDriver
+ contrib/retep/uk/org/retep/tools.properties
+ contrib/retep/uk/org/retep/dtu/DCollection.java
+ src/interfaces/jdbc/utils/CheckVersion.java
src/interfaces/jdbc/utils/changelog.pl
src/interfaces/jdbc/Implementation
! contrib/retep/uk/org/retep/dtu/DModuleXML.java
src/interfaces/jdbc/CHANGELOG
src/interfaces/jdbc/jdbc.jpx

***************
*** 304487,304494 ****
A contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
A contrib/retep/uk/org/retep/util/proped/Main.java
A contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- A contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- A contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
A contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
A contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
A contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 304393,304398 ----
***************
*** 306056,306063 ****
D contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
D contrib/retep/uk/org/retep/util/proped/Main.java
D contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
D contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 305960,305965 ----
***************
*** 306159,306165 ****
jdbc/utils/changelog.pl

M src/interfaces/jdbc/Makefile
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
D src/interfaces/jdbc/utils/CheckVersion.java
D src/interfaces/jdbc/utils/buildDriver
--- 306061,306066 ----
***************
*** 310347,310356 ****
M src/interfaces/jdbc/org/postgresql/PGConnection.java
M src/interfaces/jdbc/org/postgresql/PGNotification.java
M src/interfaces/jdbc/org/postgresql/PGStatement.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/Notification.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- M src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
--- 310248,310253 ----
***************
*** 312352,312359 ****
M src/interfaces/jdbc/org/postgresql/PGConnection.java
A src/interfaces/jdbc/org/postgresql/PGNotification.java
M src/interfaces/jdbc/org/postgresql/PGStatement.java
- A src/interfaces/jdbc/org/postgresql/core/Notification.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
--- 312249,312254 ----
***************
*** 314599,314605 ****
jdbc/org/postgresql/jdbc2/AbstractJdbc2Statement.java
jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java

- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
M src/interfaces/jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
--- 314494,314499 ----
***************
*** 315610,315622 ****

M src/interfaces/jdbc/org/postgresql/Driver.java.in
M src/interfaces/jdbc/org/postgresql/PG_Stream.java
- D src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- D src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- D src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- D src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- D src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java

! commit c43760a7143b3f1f0c746e907849bf77b8674c36 refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Aug 20 02:20:48 2002 +0000

--- 315504,315511 ----

M src/interfaces/jdbc/org/postgresql/Driver.java.in
M src/interfaces/jdbc/org/postgresql/PG_Stream.java

! commit 353e8d63887ff6ce9b189e351237b5c4be7c0149 refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Aug 20 02:20:48 2002 +0000

***************
*** 319778,319784 ****
A src/interfaces/jdbc/org/postgresql/PGStatement.java
D src/interfaces/jdbc/org/postgresql/ResultSet.java
D src/interfaces/jdbc/org/postgresql/Statement.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
A src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
A src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1ResultSet.java
--- 319667,319672 ----
***************
*** 322769,322779 ****
A src/test/regress/expected/rangefuncs.out
A src/test/regress/sql/rangefuncs.sql

! commit 36288fbd202ea55fe602e5c34dac4945421e1974 refs/heads/ecpg_big_bison
! Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
Date: Thu Jun 20 20:29:55 2002 +0000

! This commit was manufactured by cvs2svn to create branch 'ecpg_big_bison'.

Sprout from master 2002-06-20 20:29:54 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Update copyright to 2002.'
Delete:
--- 322657,322667 ----
A src/test/regress/expected/rangefuncs.out
A src/test/regress/sql/rangefuncs.sql

! commit 6b45cd034bde6e49a84e71c11b34a1f99211f8ff refs/remotes/origin/ecpg_big_bison
! Author: Git to CVS conversion script <webmaster(at)postgresql(dot)org>
Date: Thu Jun 20 20:29:55 2002 +0000

! This commit was manufactured by cvs2git to create branch 'ecpg_big_bison'.

Sprout from master 2002-06-20 20:29:54 UTC Bruce Momjian <bruce(at)momjian(dot)us> 'Update copyright to 2002.'
Delete:
***************
*** 323040,323047 ****
contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
contrib/retep/uk/org/retep/util/proped/Main.java
contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 322928,322933 ----
***************
*** 324680,324693 ****
src/interfaces/jdbc/org/postgresql/PostgresqlDataSource.java
src/interfaces/jdbc/org/postgresql/ResultSet.java
src/interfaces/jdbc/org/postgresql/Statement.java
- src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- src/interfaces/jdbc/org/postgresql/core/Encoding.java
- src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
- src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
src/interfaces/jdbc/org/postgresql/errors.properties
src/interfaces/jdbc/org/postgresql/errors_de.properties
src/interfaces/jdbc/org/postgresql/errors_fr.properties
--- 324566,324571 ----
***************
*** 325736,325743 ****
D contrib/retep/uk/org/retep/util/models/PropertiesTableModel.java
D contrib/retep/uk/org/retep/util/proped/Main.java
D contrib/retep/uk/org/retep/util/proped/PropertyEditor.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- D contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
D contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
D contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 325614,325619 ----
***************
*** 327376,327389 ****
D src/interfaces/jdbc/org/postgresql/PostgresqlDataSource.java
D src/interfaces/jdbc/org/postgresql/ResultSet.java
D src/interfaces/jdbc/org/postgresql/Statement.java
- D src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- D src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- D src/interfaces/jdbc/org/postgresql/core/Encoding.java
- D src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- D src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- D src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- D src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
- D src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
D src/interfaces/jdbc/org/postgresql/errors.properties
D src/interfaces/jdbc/org/postgresql/errors_de.properties
D src/interfaces/jdbc/org/postgresql/errors_fr.properties
--- 327252,327257 ----
***************
*** 336274,336281 ****

M src/interfaces/jdbc/org/postgresql/Connection.java
M src/interfaces/jdbc/org/postgresql/Driver.java.in
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- D src/interfaces/jdbc/org/postgresql/core/QueryExecutor2.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java

--- 336142,336147 ----
***************
*** 336758,336778 ****

M src/bin/pg_dump/pg_dump.c

! commit 78d40a2a2f415071e82a6be9667ba96d398856ab refs/tags/REL7_4_BETA1
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Thu Mar 21 03:20:30 2002 +0000
!
! Two versions of QueryExecutor, currently only version 2 works 100%
! these versions adhere to the backend protocol better than previous version
! fixes problem when an error occurs on the backend, and the connection is still used
! previous versions were throwing an exception half way through the protocol, leaving it
! indeterminate.
! also removes empty query code, should speed things up a bit
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
! A src/interfaces/jdbc/org/postgresql/core/QueryExecutor2.java
!
! commit 54cc549d8f2505fa4a3bd0aae382247497a4c613 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Thu Mar 21 02:52:37 2002 +0000

--- 336624,336630 ----

M src/bin/pg_dump/pg_dump.c

! commit a7b0aad3040b9d117b6d2510ab2961ea584cb5bc refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Thu Mar 21 02:52:37 2002 +0000

***************
*** 336783,336797 ****

M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java

! commit 00923229c2f076d241daf03dbc05e1458539c6d3 refs/tags/REL7_4_BETA1
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Thu Mar 21 02:40:03 2002 +0000
!
! Part of Anders Bengtsson's patch to clean up Connection.java
!
! A src/interfaces/jdbc/org/postgresql/core/StartupPacket.java
!
! commit d96c29ab301ac22488cf8443e1da819826c47ac1 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Thu Mar 21 02:39:06 2002 +0000

--- 336635,336641 ----

M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java

! commit 5f629417b24f473116f65d078ecd71008b86524d refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Thu Mar 21 02:39:06 2002 +0000

***************
*** 337058,337086 ****

M src/backend/utils/adt/ri_triggers.c

! commit eb1fb8650fb2b12d93f8c20cdb97c772ede944de refs/tags/REL7_4_BETA1
! Author: Bruce Momjian <bruce(at)momjian(dot)us>
! Date: Tue Mar 19 02:48:45 2002 +0000
!
! >Added ServerEncoding
! > Korean (JOHAB), Thai (WIN874),
! > Vietnamese (TCVN), Arabic (WIN1256)
! >
! >Added ClientEncoding
! > Simplified Chinese (GBK), Korean (UHC)
! >
! >Add PsqlODBC and document ...etc patch.
!
!
! "JDBC patch" is delivered, too. :-)
!
!
!
! Eiji Tokuya
!
! M src/interfaces/jdbc/org/postgresql/core/Encoding.java
!
! commit d3337c6e3f9bca1c98ca8e3de218b0e2a5d2f29d refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Mar 19 02:47:57 2002 +0000

--- 336902,336908 ----

M src/backend/utils/adt/ri_triggers.c

! commit 60b39ed9687c43f2f93d1e5138f5baa7550301a0 refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Mar 19 02:47:57 2002 +0000

***************
*** 337247,337262 ****
M doc/FAQ
M doc/src/FAQ/FAQ.html

! commit 202a19e47bfd3a28dc1ec7ef73d15c05a532bd13 refs/tags/REL7_4_BETA1
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Mon Mar 18 04:16:33 2002 +0000
!
! Fixes bug where query hangs if there is an error in the query, went back to
! code before QueryExecutor class was created and copied behaviour
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
!
! commit bbc1fb07c62526469af4896a634b895623d403a1 refs/tags/REL7_2_3
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Mar 17 20:05:59 2002 +0000

--- 337069,337075 ----
M doc/FAQ
M doc/src/FAQ/FAQ.html

! commit 5e4dae0b37104f7255c104f464091495e01d0ef7 refs/tags/REL7_2_3
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Mar 17 20:05:59 2002 +0000

***************
*** 337288,337296 ****

M src/backend/utils/adt/arrayfuncs.c

! commit 134fe5ec61cb280459a4782b6d465e115c5ac5a8 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Sat Mar 16 02:15:23 2002 +0000

fixed QueryExecuter to deal with multiple errors
previously it was throwing a SQLException as soon as the error message was
--- 337101,337109 ----

M src/backend/utils/adt/arrayfuncs.c

! commit e90d2c594d0146ce2eef96799969105cfd71d41c refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Sat Mar 16 02:15:22 2002 +0000

fixed QueryExecuter to deal with multiple errors
previously it was throwing a SQLException as soon as the error message was
***************
*** 337300,337308 ****
Also added setLogLevel to Driver.java, and made the log levels public

M src/interfaces/jdbc/org/postgresql/Driver.java.in
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java

! commit efec53adb3a35b5ebbff3f12a0063685c1cd3e09 refs/tags/REL7_2_3
Author: Thomas G. Lockhart <lockhart(at)fourpalms(dot)org>
Date: Fri Mar 15 23:37:48 2002 +0000

--- 337113,337120 ----
Also added setLogLevel to Driver.java, and made the log levels public

M src/interfaces/jdbc/org/postgresql/Driver.java.in

! commit 13506210df646063a74d36b5c0a46e7ed58a11d4 refs/tags/REL7_2_3
Author: Thomas G. Lockhart <lockhart(at)fourpalms(dot)org>
Date: Fri Mar 15 23:37:48 2002 +0000

***************
*** 338451,338465 ****

M src/interfaces/jdbc/org/postgresql/jdbc2/Statement.java

! commit ffe356b5dd39ce5e48546d1f6299c6c6897eb501 refs/tags/REL7_4_BETA1
! Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Tue Mar 5 20:11:57 2002 +0000
!
! backed out changes for cancel, no need to look for two 'Z' responses
!
! M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
!
! commit 29ea8ff9b13f7e4e42d18a04a46e5cc3d8f9cfd2 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Tue Mar 5 18:02:44 2002 +0000

--- 338263,338269 ----

M src/interfaces/jdbc/org/postgresql/jdbc2/Statement.java

! commit 3ae2c4b06f6322a3cb777f08b59edec35099e409 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
Date: Tue Mar 5 18:02:44 2002 +0000

***************
*** 338468,338483 ****
M src/interfaces/jdbc/org/postgresql/ResultSet.java
M src/interfaces/jdbc/org/postgresql/Statement.java

! commit ff2f9b663f73b020cc5f8fa05d848a6f6d33c6ac refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Tue Mar 5 18:01:27 2002 +0000

fixed cancel query bug introduced by patch

M src/interfaces/jdbc/org/postgresql/Connection.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java

! commit b7cc409f7f5e81628a2c62da15f013ec33714392 refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Mar 5 17:55:45 2002 +0000

--- 338272,338286 ----
M src/interfaces/jdbc/org/postgresql/ResultSet.java
M src/interfaces/jdbc/org/postgresql/Statement.java

! commit 73de87d505c9079b484c8fbb17c5a08a8b12a018 refs/tags/REL7_4_BETA1
Author: Dave Cramer <davec(at)fastcrypt(dot)com>
! Date: Tue Mar 5 18:00:36 2002 +0000

fixed cancel query bug introduced by patch

M src/interfaces/jdbc/org/postgresql/Connection.java

! commit 54c3f680c2366db831f1ce45d23f991e132f963e refs/tags/REL7_4_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Tue Mar 5 17:55:45 2002 +0000

***************
*** 346690,346696 ****
M src/interfaces/jdbc/org/postgresql/Connection.java
M src/interfaces/jdbc/org/postgresql/ResultSet.java
M src/interfaces/jdbc/org/postgresql/Statement.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java
M src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
--- 346493,346498 ----
***************
*** 347466,347474 ****
M src/interfaces/jdbc/example/corba/StockServer.java
M src/interfaces/jdbc/example/psql.java
M src/interfaces/jdbc/org/postgresql/Connection.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- M src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
M src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java
M src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java
M src/interfaces/jdbc/org/postgresql/util/Serialize.java
--- 347268,347273 ----
***************
*** 347502,347510 ****
M src/interfaces/jdbc/org/postgresql/PG_Stream.java
M src/interfaces/jdbc/org/postgresql/PostgresqlDataSource.java
M src/interfaces/jdbc/org/postgresql/Statement.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/geometric/PGpath.java
M src/interfaces/jdbc/org/postgresql/jdbc1/DatabaseMetaData.java
--- 347301,347306 ----
***************
*** 347564,347576 ****
M src/interfaces/jdbc/org/postgresql/PostgresqlDataSource.java
M src/interfaces/jdbc/org/postgresql/ResultSet.java
M src/interfaces/jdbc/org/postgresql/Statement.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- M src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- M src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/fastpath/FastpathArg.java
M src/interfaces/jdbc/org/postgresql/geometric/PGbox.java
--- 347360,347365 ----
***************
*** 351265,351277 ****
M src/interfaces/jdbc/org/postgresql/PostgresqlDataSource.java
M src/interfaces/jdbc/org/postgresql/ResultSet.java
M src/interfaces/jdbc/org/postgresql/Statement.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- M src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- M src/interfaces/jdbc/org/postgresql/core/Encoding.java
- M src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- M src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
- M src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
M src/interfaces/jdbc/org/postgresql/fastpath/Fastpath.java
M src/interfaces/jdbc/org/postgresql/fastpath/FastpathArg.java
M src/interfaces/jdbc/org/postgresql/geometric/PGbox.java
--- 351054,351059 ----
***************
*** 353001,353015 ****
M src/bin/initdb/initdb.sh
M src/test/regress/expected/rules.out

! commit bf737b859f7e4e5f69b9bfff80f6d50329622e65 refs/tags/REL7_2_BETA1
! Author: Barry Lind <barry(at)xythos(dot)com>
! Date: Tue Oct 16 20:07:17 2001 +0000
!
! Updated the list of encodings supported to match what the backend now supports
!
! M src/interfaces/jdbc/org/postgresql/core/Encoding.java
!
! commit f50793c743c755e208b89dcc845e9318e6ca881f refs/tags/REL7_2_BETA1
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Tue Oct 16 20:05:22 2001 +0000

--- 352783,352789 ----
M src/bin/initdb/initdb.sh
M src/test/regress/expected/rules.out

! commit 5bd1d4cc5a9cac572f3680b8da06afd0d7551115 refs/tags/REL7_2_BETA1
Author: Barry Lind <barry(at)xythos(dot)com>
Date: Tue Oct 16 20:05:22 2001 +0000

***************
*** 353864,353870 ****

M src/interfaces/jdbc/org/postgresql/Connection.java
M src/interfaces/jdbc/org/postgresql/ResultSet.java
- M src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
M src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
M src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java
--- 353638,353643 ----
***************
*** 359103,359112 ****

Add missing files.

- A src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
A src/interfaces/jdbc/org/postgresql/jdbc2/PBatchUpdateException.java

! commit 311eef41ea01ceb8ee2e331b788ed68da4c9dda5 refs/tags/REL7_2_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Thu Sep 6 03:46:09 2001 +0000

--- 358876,358884 ----

Add missing files.

A src/interfaces/jdbc/org/postgresql/jdbc2/PBatchUpdateException.java

! commit 7624f6521cd8508eb7e2e84bc6b9e5b27efa39d9 refs/tags/REL7_2_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Thu Sep 6 03:46:09 2001 +0000

***************
*** 363464,363470 ****
M src/interfaces/jdbc/Implementation
M src/interfaces/jdbc/org/postgresql/Connection.java
M src/interfaces/jdbc/org/postgresql/PG_Stream.java
- A src/interfaces/jdbc/org/postgresql/core/Encoding.java
M src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
M src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
A src/interfaces/jdbc/org/postgresql/test/EncodingTest.java
--- 363236,363241 ----
***************
*** 364688,364702 ****

M src/backend/parser/analyze.c

! commit 5621ec0629b1da42869375210b2a90e6605dd9f0 refs/tags/REL7_2_BETA1
! Author: Bruce Momjian <bruce(at)momjian(dot)us>
! Date: Wed Jul 4 15:57:25 2001 +0000
!
! Remove ConnectionHook.java. No longer used, bad code.
!
! D src/interfaces/jdbc/org/postgresql/core/ConnectionHook.java
!
! commit 0e4d43f4593cda055d15641e0edce424b0b84fab refs/tags/REL7_2_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Wed Jul 4 15:09:54 2001 +0000

--- 364459,364465 ----

M src/backend/parser/analyze.c

! commit 3c54539a71d93287f7efd373237dff33480603f8 refs/tags/REL7_2_BETA1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Wed Jul 4 15:09:54 2001 +0000

***************
*** 375738,375747 ****
Minor fixes...

M src/interfaces/jdbc/org/postgresql/Driver.java.in
- A src/interfaces/jdbc/org/postgresql/core/ConnectionHook.java
M src/interfaces/jdbc/org/postgresql/jdbc2/CallableStatement.java

! commit e2e84a1c5e137111a2d11e21423af204344190c5 refs/tags/REL7_1
Author: Peter Mount <peter(at)retep(dot)org(dot)uk>
Date: Mon Mar 5 09:15:38 2001 +0000

--- 375501,375509 ----
Minor fixes...

M src/interfaces/jdbc/org/postgresql/Driver.java.in
M src/interfaces/jdbc/org/postgresql/jdbc2/CallableStatement.java

! commit e9a341bd1bb801787c63202f06894167a508c8ad refs/tags/REL7_1
Author: Peter Mount <peter(at)retep(dot)org(dot)uk>
Date: Mon Mar 5 09:15:38 2001 +0000

***************
*** 380554,380572 ****
M src/interfaces/odbc/psqlodbc.rc
M src/interfaces/odbc/resource.h

! commit 4e45005ffb8f89ce055953ea66dde908be7c26ed refs/tags/REL7_1
! Author: Bruce Momjian <bruce(at)momjian(dot)us>
! Date: Thu Jan 25 00:02:58 2001 +0000
!
! This patch fixes an arrayindexoutofbounds exception that was just
! introduced into the code. The fix is a fix to
! org.postgresql.core.ByteArrayDim1.java.
!
! Barry Lind
!
! M src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
!
! commit ba6fda5191a188b04a953b304be5eaf04fc3f902 refs/tags/REL7_1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Thu Jan 25 00:01:17 2001 +0000

--- 380316,380322 ----
M src/interfaces/odbc/psqlodbc.rc
M src/interfaces/odbc/resource.h

! commit 233ba6a69f637597ae61682dd1366c2c89f20217 refs/tags/REL7_1
Author: Bruce Momjian <bruce(at)momjian(dot)us>
Date: Thu Jan 25 00:01:17 2001 +0000

***************
*** 381729,381736 ****
A contrib/retep/data/cds.dtd
A contrib/retep/data/cds.xml
M contrib/retep/retep.jpx
- A contrib/retep/uk/org/retep/xml/core/XMLFactory.java
- A contrib/retep/uk/org/retep/xml/core/XMLFactoryException.java
A contrib/retep/uk/org/retep/xml/jdbc/XMLDatabase.java
A contrib/retep/uk/org/retep/xml/jdbc/XMLResultSet.java
M contrib/retep/uk/org/retep/xml/parser/TagHandler.java
--- 381479,381484 ----
***************
*** 382777,382787 ****
A src/interfaces/jdbc/jdbc.jpx
M src/interfaces/jdbc/org/postgresql/Connection.java
M src/interfaces/jdbc/org/postgresql/PG_Stream.java
- A src/interfaces/jdbc/org/postgresql/core/BytePoolDim1.java
- A src/interfaces/jdbc/org/postgresql/core/BytePoolDim2.java
- A src/interfaces/jdbc/org/postgresql/core/MemoryPool.java
- A src/interfaces/jdbc/org/postgresql/core/ObjectPool.java
- A src/interfaces/jdbc/org/postgresql/core/SimpleObjectPool.java
M src/interfaces/jdbc/org/postgresql/errors.properties
M src/interfaces/jdbc/org/postgresql/jdbc1/Statement.java
M src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
--- 382525,382530 ----

On Fri, Sep 17, 2010 at 18:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> Magnus posted an updated conversion this morning.
>>>
>>>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>>>
>>>> Evidently, however, he didn't do the same things you did, because
>>>> there are DEFINITELY more than 9 manufactured commits in this one.
>>>
>>> Um ... I just did
>>>        git clone git://git.postgresql.org/git/postgresql-migration.git
>>> and I only see nine.  It's got some *other* problems though; compared
>>> to a conversion I just finished locally, it's missing a whole lot of
>>> history for some of the old jdbc files.
>>>
>>> Is there any possibility that "git clone" isn't very trustworthy?
>>> It's a bit scary that we don't see identical views of this repository.
>>
>> *scratches head*
>>
>> I did a git-fetch into an existing copy of the old contents of that
>> repository, rather than a fresh clone.  Let me nuke it and start over.
>
> OK, the fresh clone does in fact show just 9 manufactured commits.
> Sorry, I must not have cleaned out the old state properly.

Turns out I did th esame thing from my box to the repo on git.postgresql.org.

So I've now wiped that repository and re-pushed mine. Can you give it
another check? (from a fresh clone)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Fri, Sep 17, 2010 at 18:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Sorry, I must not have cleaned out the old state properly.

> Turns out I did th esame thing from my box to the repo on git.postgresql.org.

> So I've now wiped that repository and re-pushed mine. Can you give it
> another check? (from a fresh clone)

I re-cloned but got the exact same state as before --- jdbc still wonky.

regards, tom lane

On Fri, Sep 17, 2010 at 19:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Fri, Sep 17, 2010 at 18:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Sorry, I must not have cleaned out the old state properly.
>
>> Turns out I did th esame thing from my box to the repo on git.postgresql.org.
>
>> So I've now wiped that repository and re-pushed mine. Can you give it
>> another check? (from a fresh clone)
>
> I re-cloned but got the exact same state as before --- jdbc still wonky.

That's weird.

Just to confirm, you ran your patch against current cvs, right? So you
also got the "hunk succeeded at offset 1 line" a whole bunch of times?
Then it's not that that's broken.

And I'm on cvs2git revision 5270.

The script I've run is on http://github.com/mhagander/pggit_migrate -
it's the "migrate_cvs.sh" script. The repository_fixups script is a
direct import of yours except I added a "set -e" at the start.

(the version pushed hasn't had the git gc step run, but that's the
only one that differs)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Just to confirm, you ran your patch against current cvs, right? So you
> also got the "hunk succeeded at offset 1 line" a whole bunch of times?
> Then it's not that that's broken.

Right, the patch still applies fine, it's just off by a line or so in
many places (probably because of the new REL9_0_0 tags).

> The script I've run is on http://github.com/mhagander/pggit_migrate -
> it's the "migrate_cvs.sh" script. The repository_fixups script is a
> direct import of yours except I added a "set -e" at the start.

Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
and tar'd up the /cvsroot directory ;-). I wonder if there's something
wrong with the anoncvs copy of that subdirectory? Will do the rsync
and compare.

regards, tom lane

I wrote:
> Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
> and tar'd up the /cvsroot directory ;-). I wonder if there's something
> wrong with the anoncvs copy of that subdirectory? Will do the rsync
> and compare.

Doh:

Only in myrepo/pgsql/contrib/retep/uk/org/retep/xml: core
Only in myrepo/pgsql/src/interfaces/jdbc/org/postgresql: core

Something in the rsync process thinks that ignoring subdirectories
named "core" is a good idea. I'm a bit surprised nobody ever noticed
these were missing from anoncvs before ...

regards, tom lane

On Fri, Sep 17, 2010 at 20:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Hmm.  I didn't try rsync'ing from anoncvs ... I logged into the master
>> and tar'd up the /cvsroot directory ;-).  I wonder if there's something
>> wrong with the anoncvs copy of that subdirectory?  Will do the rsync
>> and compare.
>
> Doh:
>
> Only in myrepo/pgsql/contrib/retep/uk/org/retep/xml: core
> Only in myrepo/pgsql/src/interfaces/jdbc/org/postgresql: core
>
> Something in the rsync process thinks that ignoring subdirectories
> named "core" is a good idea.  I'm a bit surprised nobody ever noticed
> these were missing from anoncvs before ...

Oh FFS..

It's the adding of -C to the commandline to rsync. And it's not added
when syncing to anoncvs - it's there on anoncvs.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

I wrote:
> Something in the rsync process thinks that ignoring subdirectories
> named "core" is a good idea. I'm a bit surprised nobody ever noticed
> these were missing from anoncvs before ...

That's because they aren't. It's the -C switch in your rsync call
that's at fault. (And this demonstrates why comparing against checkouts
from the same CVS repo isn't an end-to-end test :-()

regards, tom lane

On Fri, Sep 17, 2010 at 20:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Something in the rsync process thinks that ignoring subdirectories
>> named "core" is a good idea.  I'm a bit surprised nobody ever noticed
>> these were missing from anoncvs before ...
>
> That's because they aren't.  It's the -C switch in your rsync call
> that's at fault.  (And this demonstrates why comparing against checkouts
> from the same CVS repo isn't an end-to-end test :-()

Yeah, I noticed that too. Re-running now.

FWIW, I got thecommand off the wiki's recommendations for how to use rsync....

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
with the proposed clean_keywords.pl script. I'd like it to reduce the
$PostgreSQL$ thingies to the full pathname of the file, rather than
try to remove all trace of them, eg
* $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
becomes
* src/port/unsetenv.c

This would then be followed up by moving those pathname comments to
somewhere more sensible. I don't think that part can be managed with
a script like this, but leaving the data in place will make it easier
to do the moving. Some places, like the .sgml files, won't need any
additional changing to get to where I would like to be.

Also, I'd be inclined to make these changes only in master, not in the
back branches. We don't for example run pg_indent against back branches.

regards, tom lane

On 09/17/2010 02:37 PM, Magnus Hagander wrote:
> On Fri, Sep 17, 2010 at 20:32, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wrote:
>>> Something in the rsync process thinks that ignoring subdirectories
>>> named "core" is a good idea. I'm a bit surprised nobody ever noticed
>>> these were missing from anoncvs before ...
>> That's because they aren't. It's the -C switch in your rsync call
>> that's at fault. (And this demonstrates why comparing against checkouts
>> from the same CVS repo isn't an end-to-end test :-()
> Yeah, I noticed that too. Re-running now.
>
> FWIW, I got thecommand off the wiki's recommendations for how to use rsync....
>
>

This is what I have been using for a very long time:

rsync -avzH --delete --exclude-from=/home/cvsmirror/pg-exclude
anoncvs.postgresql.org::pgsql-cvs /home/cvsmirror/pg

The exclude file contains:

/sup/
/CVSROOT/loginfo*
/CVSROOT/commitinfo*
/CVSROOT/config*
/CVSROOT/passwd
/CVSROOT/history

cheers

andrew

On Fri, Sep 17, 2010 at 20:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I looked a bit more at your pggit_migrate stuff.  I'm not terribly happy
> with the proposed clean_keywords.pl script.  I'd like it to reduce the
> $PostgreSQL$ thingies to the full pathname of the file, rather than
> try to remove all trace of them, eg
>  *        $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
> becomes
>  *        src/port/unsetenv.c
>
> This would then be followed up by moving those pathname comments to
> somewhere more sensible.  I don't think that part can be managed with
> a script like this, but leaving the data in place will make it easier
> to do the moving.  Some places, like the .sgml files, won't need any
> additional changing to get to where I would like to be.
>
> Also, I'd be inclined to make these changes only in master, not in the
> back branches.  We don't for example run pg_indent against back branches.

We discussed that before, and the consensus then was to do that, and
backport it to *active* backbranches. Just to not demove the lines,
but replace them with an empty one so that line numbers would stay the
same.

But it's not too late to change that again... Shouldn't be too hard to
change the script to change it the way you suggest, and it's
*certainly* not hard to restrict it to just to the master branch...

Will not doing the backbranches make it harder to backport patches?
Probably shouldn't, unless you're changing the very first line of the
file, right?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Will not doing the backbranches make it harder to backport patches?
> Probably shouldn't, unless you're changing the very first line of the
> file, right?

The $PostgreSQL$ lines haven't been a backporting problem in the past,
so I don't see why they'd be one now.

regards, tom lane

On Fri, Sep 17, 2010 at 20:37, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Fri, Sep 17, 2010 at 20:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wrote:
>>> Something in the rsync process thinks that ignoring subdirectories
>>> named "core" is a good idea.  I'm a bit surprised nobody ever noticed
>>> these were missing from anoncvs before ...
>>
>> That's because they aren't.  It's the -C switch in your rsync call
>> that's at fault.  (And this demonstrates why comparing against checkouts
>> from the same CVS repo isn't an end-to-end test :-()
>
> Yeah, I noticed that too. Re-running now.

Ok, re-run off a correct rsync pushed. How does it look now?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

BTW, on the cleanup steps:

# Remove bogus branches
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D unlabeled-1.87.2
git branch -D unlabeled-1.90.2

You should not need any of the above; I don't see those being generated
anymore with the cleanup script in place.

git branch -D ecpg_big_bison

I don't agree with removing this. It is a legitimate part of the
project history. Yeah, it was a workaround, but we've had workarounds
in place for other broken software.

# Remove broken tags
git tag -d SUPPORT
git tag -d MANUAL_1_0
git tag -d Release-1-6-0

Also get rid of the "creation" tag, please. Also, just for the record,
these aren't really broken. Maybe "Remove unwanted partial tags"?

In addition to the above, we're going to want to clean up the
Release_2_0_0 and Release_2_0 tags, but I'm not sure if there's
a reasonable way to script those when the commit SHA1's aren't frozen
yet. I can give you timestamps for the commits they should point at,
but I lack the git-fu to convert that into a git tag command.

Similarly, we're going to want to repoint REL6_5, REL7_1, REL7_1_2
tags at more appropriate places, but right now all I have for those is
timestamps. (I've also identified places to tag the other early
releases, but those tags can certainly be added later.)

regards, tom lane

I wrote:
> In addition to the above, we're going to want to clean up the
> Release_2_0_0 and Release_2_0 tags, but I'm not sure if there's
> a reasonable way to script those when the commit SHA1's aren't frozen
> yet. I can give you timestamps for the commits they should point at,
> but I lack the git-fu to convert that into a git tag command.

> Similarly, we're going to want to repoint REL6_5, REL7_1, REL7_1_2
> tags at more appropriate places, but right now all I have for those is
> timestamps. (I've also identified places to tag the other early
> releases, but those tags can certainly be added later.)

Actually, the simplest way to handle this might be to just delete all
five of those tags during the conversion, and then I'll put them back
in the right places later when I add the other old-release tags.
That way we won't have any tags getting moved after the repository is
published. (Or am I wrong about that being something to avoid? But
in any case we want to gc the manufactured commits for Release_2_0_0
and Release_2_0.)

regards, tom lane

On Fri, Sep 17, 2010 at 23:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> BTW, on the cleanup steps:
>
> # Remove bogus branches
> git branch -D unlabeled-1.44.2
> git branch -D unlabeled-1.51.2
> git branch -D unlabeled-1.59.2
> git branch -D unlabeled-1.87.2
> git branch -D unlabeled-1.90.2
>
> You should not need any of the above; I don't see those being generated
> anymore with the cleanup script in place.

I see them - at least the script didn't give an error when it ran, but
said it had deleted them.

> git branch -D ecpg_big_bison
>
> I don't agree with removing this.  It is a legitimate part of the
> project history.  Yeah, it was a workaround, but we've had workarounds
> in place for other broken software.

Ok. I was just going by Michaels email - I'll leave it in then.

> # Remove broken tags
> git tag -d SUPPORT
> git tag -d MANUAL_1_0
> git tag -d Release-1-6-0
>
> Also get rid of the "creation" tag, please.  Also, just for the record,
> these aren't really broken.  Maybe "Remove unwanted partial tags"?

Right. I didn't really pay much attention to the comments, since it's
just a temporary thing.
"creation" added to the list.

> In addition to the above, we're going to want to clean up the
> Release_2_0_0 and Release_2_0 tags, but I'm not sure if there's
> a reasonable way to script those when the commit SHA1's aren't frozen
> yet.  I can give you timestamps for the commits they should point at,
> but I lack the git-fu to convert that into a git tag command.

yeah, that's definitely easier to do after the fact.

> Similarly, we're going to want to repoint REL6_5, REL7_1, REL7_1_2
> tags at more appropriate places, but right now all I have for those is
> timestamps.  (I've also identified places to tag the other early
> releases, but those tags can certainly be added later.)

I like your downthread suggestion of removing them, and then putting
them back in manually later. I'll add them all to the delete list.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Fri, Sep 17, 2010 at 23:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Actually, the simplest way to handle this might be to just delete all
> five of those tags during the conversion, and then I'll put them back
> in the right places later when I add the other old-release tags.
> That way we won't have any tags getting moved after the repository is
> published.  (Or am I wrong about that being something to avoid?  But
> in any case we want to gc the manufactured commits for Release_2_0_0
> and Release_2_0.)

As long as nobody has cloned the repository, it's not a problem moving
them. But it *is* something you should generally avoid, so let's do
that :-)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Fri, Sep 17, 2010 at 23:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> git branch -D unlabeled-1.44.2
>> git branch -D unlabeled-1.51.2
>> git branch -D unlabeled-1.59.2
>> git branch -D unlabeled-1.87.2
>> git branch -D unlabeled-1.90.2
>>
>> You should not need any of the above; I don't see those being generated
>> anymore with the cleanup script in place.

> I see them - at least the script didn't give an error when it ran, but
> said it had deleted them.

[ scratches head ... ] That's weird. We probably ought to figure out
why you and I are getting different results. I wonder if there's some
other discrepancy in the anoncvs pull?

Anyway, if what you have up at
http://github.com/mhagander/pggit_migrate
is current, I can try to reproduce your results here.

regards, tom lane

On Sat, Sep 18, 2010 at 00:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Fri, Sep 17, 2010 at 23:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> git branch -D unlabeled-1.44.2
>>> git branch -D unlabeled-1.51.2
>>> git branch -D unlabeled-1.59.2
>>> git branch -D unlabeled-1.87.2
>>> git branch -D unlabeled-1.90.2
>>>
>>> You should not need any of the above; I don't see those being generated
>>> anymore with the cleanup script in place.
>
>> I see them - at least the script didn't give an error when it ran, but
>> said it had deleted them.
>
> [ scratches head ... ]  That's weird.  We probably ought to figure out
> why you and I are getting different results.  I wonder if there's some
> other discrepancy in the anoncvs pull?

Could be.

> Anyway, if what you have up at
> http://github.com/mhagander/pggit_migrate
> is current, I can try to reproduce your results here.

It is - I just double-checked that.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Sep 18, 2010 at 00:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> [ scratches head ... ] That's weird. We probably ought to figure out
>> why you and I are getting different results. I wonder if there's some
>> other discrepancy in the anoncvs pull?

> Could be.

Oh, mystery explained upon comparing the cvs2git.options files.
I was using Max's file which had this in it:

ExcludeRegexpStrategyRule(r'unlabeled-.*'),

I think I'll rerun without that just to convince myself of what it is
we're dropping. But right now it seems that everything is pretty sane.

regards, tom lane

I wrote:
> Oh, mystery explained upon comparing the cvs2git.options files.
> I was using Max's file which had this in it:
> ExcludeRegexpStrategyRule(r'unlabeled-.*'),
> I think I'll rerun without that just to convince myself of what it is
> we're dropping. But right now it seems that everything is pretty sane.

OK, I found out what we're dropping. Those "unlabeled" branches each
have a manufactured creation commit that just deletes a lot of files,
plus a single real commit, which all look like this:

+ commit 6c23cb5f371f273cade66408f3a888c2f94af293 refs/heads/unlabeled-1.51.2
+ Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
+ Date: Sat Sep 28 20:00:29 2002 +0000
+
+ Make the world at least somewhat safe for zero-column tables, and
+ remove the special case in ALTER DROP COLUMN to prohibit dropping a
+ table's last column.
+
+ M src/test/regress/expected/alter_table.out
+
+ commit d554d56827e4337835b0792c2568e8e9fee2d950 refs/heads/unlabeled-1.87.2
+ Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
+ Date: Sat Sep 28 20:00:28 2002 +0000
+
+ Make the world at least somewhat safe for zero-column tables, and
+ remove the special case in ALTER DROP COLUMN to prohibit dropping a
+ table's last column.
+
+ M src/backend/executor/nodeAgg.c
+
+ commit 7724eba3a121e5c84da3467fe6f0b176bf3f3d4b refs/heads/unlabeled-1.59.2
+ Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
+ Date: Sat Sep 28 20:00:27 2002 +0000
+
+ Make the world at least somewhat safe for zero-column tables, and
+ remove the special case in ALTER DROP COLUMN to prohibit dropping a
+ table's last column.
+
+ M src/backend/executor/execTuples.c
+
+ commit 6924390f0cfa2aac1308719e51cb4cc2b24e2bc7 refs/heads/unlabeled-1.44.2
+ Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
+ Date: Sat Sep 28 20:00:26 2002 +0000
+
+ Make the world at least somewhat safe for zero-column tables, and
+ remove the special case in ALTER DROP COLUMN to prohibit dropping a
+ table's last column.
+
+ M src/backend/commands/tablecmds.c
+
+ commit 83029b0525f3324c30d35fcc9c77d2c301bdf7cf refs/heads/unlabeled-1.90.2
+ Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
+ Date: Sat Sep 28 20:00:25 2002 +0000
+
+ Make the world at least somewhat safe for zero-column tables, and
+ remove the special case in ALTER DROP COLUMN to prohibit dropping a
+ table's last column.
+
+ M src/backend/access/common/tupdesc.c
+ M src/backend/parser/parse_target.c
+
commit 6d0d15c451739396851d3f93f81c63a47535bf1e refs/tags/REL7_4_BETA1
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat Sep 28 20:00:19 2002 +0000

If you go and look at the CVS history of these files, you'll see that
indeed they all have branches sprouted on that date that are
unreferenced.

This commit occurred during that interval between where we'd initially
branched 7.3 and where we moved it up to head. I think what happened
was that I tried to back-patch a fix into what was then the 7.3 branch,
and when Marc moved the branch point, these commits all ended up
orphans. So indeed there's no harm discarding them. (I always
suspected that what Marc had done wasn't entirely kosher, and yup,
now the chickens are coming home to roost.)

regards, tom lane

I wrote:
> This commit occurred during that interval between where we'd initially
> branched 7.3 and where we moved it up to head. I think what happened
> was that I tried to back-patch a fix into what was then the 7.3 branch,
> and when Marc moved the branch point, these commits all ended up
> orphans. So indeed there's no harm discarding them. (I always
> suspected that what Marc had done wasn't entirely kosher, and yup,
> now the chickens are coming home to roost.)

BTW, if you're wondering why there was only one such commit, it's
because we decided to not maintain the branch only a day after Marc had
sprouted it. See discussion here:
http://archives.postgresql.org/pgsql-hackers/2002-09/msg01733.php

regards, tom lane

I wrote:
> I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
> with the proposed clean_keywords.pl script. I'd like it to reduce the
> $PostgreSQL$ thingies to the full pathname of the file, rather than
> try to remove all trace of them, eg
> * $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
> becomes
> * src/port/unsetenv.c

> This would then be followed up by moving those pathname comments to
> somewhere more sensible. I don't think that part can be managed with
> a script like this, but leaving the data in place will make it easier
> to do the moving. Some places, like the .sgml files, won't need any
> additional changing to get to where I would like to be.

> Also, I'd be inclined to make these changes only in master, not in the
> back branches. We don't for example run pg_indent against back branches.

Pursuant to that, attached are proposed modified versions of the two
scripts involved.

regards, tom lane

On 09/19/2010 12:25 PM, Tom Lane wrote:
>
> Pursuant to that, attached are proposed modified versions of the two
> scripts involved.

> #
> # We don't want to change line numbers, so we simply reduce the keyword
> # string to the file pathname part. For example,
> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
> # becomes
> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
> #
>

These before and after lines look identical to me.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 09/19/2010 12:25 PM, Tom Lane wrote:
>> # We don't want to change line numbers, so we simply reduce the keyword
>> # string to the file pathname part. For example,
>> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
>> # becomes
>> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $

> These before and after lines look identical to me.

Sigh ... obviously didn't finish editing the comment :-(
Of course the last line should read

# src/port/unsetenv.c

regards, tom lane

On Sun, Sep 19, 2010 at 18:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 09/19/2010 12:25 PM, Tom Lane wrote:
>>> # We don't want to change line numbers, so we simply reduce the keyword
>>> # string to the file pathname part.  For example,
>>> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
>>> # becomes
>>> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian Exp $
>
>> These before and after lines look identical to me.
>
> Sigh ... obviously didn't finish editing the comment :-(
> Of course the last line should read
>
> # src/port/unsetenv.c

I've applied those to my repo, and am now re-running a final
conversion before we do the "live one".

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/