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

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

+1.

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

+1.

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

Fine with me.

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

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

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

OK.

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

Great.

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

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

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

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