Re: Policy decisions and cosmetic issues remaining for the git conversion

On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> 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.

+1 from me, too.  I don't agree with statements upthread that this
will be "easier" to do in git.  I think we should fix the CVS history.The git conversion is a one-time event.  Once
it'sdone, history is 
set in stone.  We don't want to set the wrong thing in stone.

>> * 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.

Yeah.  I would leave these in CVS (why not?) but drop them from the
git conversion, which is easily done.

>> * 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

+1.

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