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

Search Discussions

  • Robert Haas at Sep 13, 2010 at 12:14 pm

    On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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
  • Tom Lane at Sep 13, 2010 at 2:13 pm

    Robert Haas 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
  • Tom Lane at Sep 13, 2010 at 3:48 pm

    Robert Haas writes:
    On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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@postgresql.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@momjian.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@momjian.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
  • Robert Haas at Sep 13, 2010 at 5:09 pm

    On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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@postgresql.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@momjian.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@momjian.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
  • Tom Lane at Sep 13, 2010 at 5:14 pm

    Robert Haas writes:
    On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Robert Haas at Sep 13, 2010 at 5:16 pm

    On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Tom Lane at Sep 13, 2010 at 5:32 pm

    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
  • Tom Lane at Sep 13, 2010 at 7:28 pm

    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
  • Magnus Hagander at Sep 13, 2010 at 7:57 pm

    On Mon, Sep 13, 2010 at 21:28, Tom Lane 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
  • Tom Lane at Sep 14, 2010 at 2:19 pm

    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?
  • Dimitri Fontaine at Sep 14, 2010 at 3:13 pm

    Tom Lane 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
  • Alvaro Herrera at Sep 14, 2010 at 4:03 pm

    Excerpts from Dimitri Fontaine's message of mar sep 14 11:10:50 -0400 2010:
    Tom Lane <tgl@sss.pgh.pa.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@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Robert Haas at Sep 14, 2010 at 3:50 pm

    On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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
  • Tom Lane at Sep 14, 2010 at 3:56 pm

    Robert Haas 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
  • Tom Lane at Sep 14, 2010 at 4:01 pm

    Robert Haas writes:
    On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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
  • Robert Haas at Sep 14, 2010 at 4:19 pm

    On Tue, Sep 14, 2010 at 12:01 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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
  • Tom Lane at Sep 14, 2010 at 4:23 pm

    Robert Haas 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
  • Robert Haas at Sep 14, 2010 at 4:31 pm

    On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Tom Lane at Sep 14, 2010 at 4:47 pm

    Robert Haas writes:
    On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Alvaro Herrera at Sep 14, 2010 at 5:22 pm

    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@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Tom Lane at Sep 14, 2010 at 5:28 pm

    Alvaro Herrera 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
  • Michael Meskes at Sep 17, 2010 at 12:29 pm

    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
  • Robert Haas at Sep 17, 2010 at 3:20 pm

    On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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
  • Tom Lane at Sep 17, 2010 at 3:39 pm

    Robert Haas 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
  • Robert Haas at Sep 17, 2010 at 3:55 pm

    On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Robert Haas at Sep 17, 2010 at 4:28 pm

    On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
    On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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
  • Tom Lane at Sep 17, 2010 at 4:41 pm

    Robert Haas writes:
    On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane 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@xythos.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@xythos.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@xythos.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@xythos.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@xythos.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@sss.pgh.pa.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@sss.pgh.pa.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@momjian.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@momjian.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@sss.pgh.pa.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@sss.pgh.pa.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@postgresql.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@sss.pgh.pa.us> 'Remove extraneous semicolons after routine bodies. These don't bother'
    Cherrypick from master 2002-09-04 07:23:04 UTC Bruce Momjian <bruce@momjian.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@postgresql.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@sss.pgh.pa.us> 'Remove extraneous semicolons after routine bodies. These don't bother'
    Cherrypick from master 2002-09-04 07:23:04 UTC Bruce Momjian <bruce@momjian.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@momjian.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@momjian.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@postgresql.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@momjian.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@postgresql.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@momjian.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@momjian.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@momjian.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@momjian.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@fastcrypt.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@sss.pgh.pa.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@sss.pgh.pa.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@fastcrypt.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@fastcrypt.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@fourpalms.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@fourpalms.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@fastcrypt.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@momjian.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@fastcrypt.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@momjian.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@xythos.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@xythos.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@xythos.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@momjian.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@momjian.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@momjian.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@momjian.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@momjian.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@retep.org.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@retep.org.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@momjian.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@momjian.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@momjian.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 ----
  • Magnus Hagander at Sep 17, 2010 at 5:04 pm

    On Fri, Sep 17, 2010 at 18:28, Robert Haas wrote:
    On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
    On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.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)
  • Tom Lane at Sep 17, 2010 at 5:20 pm

    Magnus Hagander writes:
    On Fri, Sep 17, 2010 at 18:28, Robert Haas 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
  • Magnus Hagander at Sep 17, 2010 at 5:31 pm

    On Fri, Sep 17, 2010 at 19:20, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    On Fri, Sep 17, 2010 at 18:28, Robert Haas 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)
  • Tom Lane at Sep 17, 2010 at 5:47 pm

    Magnus Hagander 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
  • Tom Lane at Sep 17, 2010 at 6:24 pm

    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
  • Magnus Hagander at Sep 17, 2010 at 6:28 pm

    On Fri, Sep 17, 2010 at 20:24, Tom Lane 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.
  • Tom Lane at Sep 17, 2010 at 6:32 pm

    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
  • Magnus Hagander at Sep 17, 2010 at 6:37 pm

    On Fri, Sep 17, 2010 at 20:32, Tom Lane 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....
  • Tom Lane at Sep 17, 2010 at 6:49 pm
    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
  • Magnus Hagander at Sep 17, 2010 at 7:02 pm

    On Fri, Sep 17, 2010 at 20:49, Tom Lane 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?
  • Tom Lane at Sep 17, 2010 at 7:28 pm

    Magnus Hagander 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
  • Tom Lane at Sep 17, 2010 at 9:01 pm
    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
  • Tom Lane at Sep 17, 2010 at 9:22 pm

    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
  • Magnus Hagander at Sep 17, 2010 at 9:35 pm

    On Fri, Sep 17, 2010 at 23:21, Tom Lane 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 at Sep 17, 2010 at 9:34 pm

    On Fri, Sep 17, 2010 at 23:01, Tom Lane 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.
  • Tom Lane at Sep 17, 2010 at 10:07 pm

    Magnus Hagander writes:
    On Fri, Sep 17, 2010 at 23:01, Tom Lane 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
  • Magnus Hagander at Sep 17, 2010 at 10:23 pm

    On Sat, Sep 18, 2010 at 00:06, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    On Fri, Sep 17, 2010 at 23:01, Tom Lane 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.
  • Tom Lane at Sep 17, 2010 at 10:58 pm

    Magnus Hagander writes:
    On Sat, Sep 18, 2010 at 00:06, Tom Lane 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
  • Tom Lane at Sep 18, 2010 at 1:29 am

    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@sss.pgh.pa.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@sss.pgh.pa.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@sss.pgh.pa.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@sss.pgh.pa.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@sss.pgh.pa.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@sss.pgh.pa.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
  • Tom Lane at Sep 18, 2010 at 4:20 pm

    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
  • Tom Lane at Sep 19, 2010 at 4:26 pm

    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
  • Andrew Dunstan at Sep 19, 2010 at 4:44 pm

    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
  • Tom Lane at Sep 19, 2010 at 4:56 pm

    Andrew Dunstan 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 13, '10 at 3:03a
activeSep 20, '10 at 11:35a
posts59
users8
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase