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