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-14T15:49:57Z
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 Tue, Sep 14, 2010 at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> * Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
> Release-1-6-0.  I think we agreed that we can just drop these tags and
> allow their manufactured commits to be garbage-collected.

+1.

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

+1.

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

Fine with me.

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

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

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

OK.

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

Great.

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

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

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

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