Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Michael Haggerty <mhagger@alum.mit.edu>, Max Bowsher <maxb@f2s.com>
Date: 2010-09-13T12:14:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Applied patch to jdbc from Kim Ho at RedHat, fixing improper handling of empty queries under the V3 protocol

  2. Applied patch for jdbc from Kim Ho at RedHat to more correctly deal with boolean values

  3. Applied patch from Oliver Jowett to improve a buffer sizing.

  4. Code cleanup inspired by recent resname bug report (doesn't fix the bug

  5. Pass shared memory id and socket descriptor number on command line for

  6. Second try at avoiding conflicts with system isblank().

  7. Applied Kris Jurkas patch to fix rollback and SQLException

  8. applied patch from Oliver Jowett

  9. Make the world at least somewhat safe for zero-column tables, and

  10. Add mention of -F not supported by pg_dumpall. Code already disallows it.

  11. Two versions of QueryExecutor, currently only version 2 works 100%

  12. modifications to the way the protocol is handled to be consistent with

  13. Part of Anders Bengtsson's patch to clean up Connection.java

  14. Applied Anders patch to move the startup code out of Connection into StartupPacket

  15. >Added ServerEncoding

  16. > I am backing out this patch. Please resubmit with this corrected. Thanks.

  17. Fixes bug where query hangs if there is an error in the query, went back to

  18. Backpatch array I/O code and documentation fixes, also array slice

  19. fixed QueryExecuter to deal with multiple errors

  20. Repair bad calculation in timetz_izone() which gave erroneous results.

  21. backed out changes for cancel, no need to look for two 'Z' responses

  22. Patch by Nicolas Verger to correctly propogate SQLWarning to the Statement and ResultSet

  23. fixed cancel query bug introduced by patch

  24. Autoconf for jdbc debug changes.

  25. Updated the list of encodings supported to match what the backend now supports

  26. Added some additional comments in the code

  27. Update TODO list.

  28. Remove ConnectionHook.java. No longer used, bad code.

  29. The attached patch removes some old and dead code (and some related

  30. First batch of the tools merged in...

  31. This patch fixes an arrayindexoutofbounds exception that was just

  32. Add ./include/config.h.win32 to RELEASE update list.

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

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

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

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

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

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

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

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

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