Re: Policy decisions and cosmetic issues remaining for the git conversion - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Policy decisions and cosmetic issues remaining for the git conversion
Date
Msg-id 1284396433-sup-295@alvh.no-ip.org
Whole thread Raw
In response to Policy decisions and cosmetic issues remaining for the git conversion  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Policy decisions and cosmetic issues remaining for the git conversion
List pgsql-hackers
Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010:

> * As I noted previously, up till about 2003 we were quite haphazard about
> applying CVS tags to identify the points where releases were made.  Should
> we try to clean that up?  I think there is a stronger case for moving the
> three existing misleading tags than for creating new tags matching the
> releases that have none.  Maybe nobody will ever care about any of them,
> but if we are trying to create a good historical record it might be
> appropriate to do it now while we have the information in mind.

+1 on both -- fixing the broken tags, and creating the missing tags,
particularly since you already seem to have found out the necessary
dates for the missing tags.

> * There are a number of partial tags (tags applied to just a subset of
> files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been
> applied to only documentation-related files, and "creation" and
> "Release-1-6-0" were applied only to src/interfaces/perl5/.  I find the
> latter two particularly misleading since they have nothing to do with
> either creation of the whole project or a "release 1.6" of the whole
> project.  These partial tags don't translate very well to git, either.
> I'm inclined to propose dropping all four.

+1 on dropping these.

> * There are a couple of manufactured commits that we could just delete,
> I think: the ones to create the Release_2_0 and Release_2_0_0 tags.  The
> tags should be reapplied to the chronologically preceding mainline commits
> instead.  This is just cosmetic but we may as well do it.  I still think
> there's a cvs2git bug underlying those.

+1

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


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Perf regression in 2.6.32 (Ubuntu 10.04 LTS)
Next
From: Robert Haas
Date:
Subject: Re: Report: removing the inconsistencies in our CVS->git conversion