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

On Mon, Sep 13, 2010 at 19:14, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)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's done, history is
> set in stone.  We don't want to set the wrong thing in stone.

Yeah, +1 on fixing it there if it needs fixing.
As noted downstream, we need to make sure it's *fixable* anyway, and
that's the larger part of the work I imagine.

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

Yeah, let's not touch the CVS side, but definitely +1 for dropping
them from git (in fact, my script does this automatically if I just
let it run through all the steps, which I've repeatedly not done which
is why they've sometimes shown up and sometimes not in the ones I've
pushed)

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

+1.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/