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

This is an attempt to sum up the open issues remaining before we can
make another try at converting our source code to git.

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

* If we do the above, should it be done in the existing CVS repository
or just as part of the conversion to git? (I suspect it'd be a lot easier
in git.) Similarly, ought we to fix the now-known tagging inconsistencies
in the CVS repository, or just leave it for the conversion to deal with?

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

* The REL8_0_0 branch needs to be downgraded to a tag, as previously
discussed.

* There are several things we should do to make the manufactured commits
less ugly, assuming we can't get rid of them entirely:
** Blame them on a nonexistent committer, probably "cvs2git" itself.
** If we do that, I'm inclined to also blame the inserted dead .0
revisions on cvs2git. Right now I copied-and-pasted the committer info
from the mainline commit they inherit from, which is not very relevant.
** Make the manufactured-commit log messages say cvs2git not cvs2svn.
** Perhaps reword the log messages for the inserted dead .0 revisions?
I didn't spend any time thinking about what they should say.

* A more aggressive answer would be to collapse the manufactured commits
for back-branch additions out of the history entirely, as was discussed
briefly earlier. I'm not sure this is worth the trouble/risk.

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

Comments?

regards, tom lane

On Mon, 2010-09-13 at 12:31 -0400, Tom Lane wrote:
> This is an attempt to sum up the open issues remaining before we can
> make another try at converting our source code to git.
>
> * 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.

It is obnoxious but I think it is a good idea.

>
> * If we do the above, should it be done in the existing CVS repository
> or just as part of the conversion to git? (I suspect it'd be a lot easier
> in git.) Similarly, ought we to fix the now-known tagging inconsistencies
> in the CVS repository, or just leave it for the conversion to deal with?

IMO eventually the CVS repo will get deleted. We should do it where it
is going to have he longest life, which would be git (or the conversion
as it was) at this point (for at least another 15 years).

Sincerely,

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

On 13/09/10 19:31, Tom Lane wrote:
> * If we do the above, should it be done in the existing CVS repository
> or just as part of the conversion to git? (I suspect it'd be a lot easier
> in git.) Similarly, ought we to fix the now-known tagging inconsistencies
> in the CVS repository, or just leave it for the conversion to deal with?

Let's leave the CVS repository as it is. I don't want to destroy the
evidence.

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

What was the purpose of these tags anyway? They don't seem useful, +1
for dropping all four.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> +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.

Well, the other side of that argument is that changing these things in
the CVS repository will be overwriting the available evidence, in case
any questions come up later. On the git side, applying the tag to the
appropriate commit is an easy --- and easily changeable --- thing, isn't
it?

regards, tom lane

On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>>> +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.
>
> Well, the other side of that argument is that changing these things in
> the CVS repository will be overwriting the available evidence, in case
> any questions come up later.  On the git side, applying the tag to the
> appropriate commit is an easy --- and easily changeable --- thing, isn't
> it?

You can apply the tag to any commit that you want easily enough, but
you can't change even the least detail of the commit contents. So if
it turns out that there's no commit that exactly matches the desired
tag contents, then things get sticky. That's why we need to make sure
that the reconstructed series of commits exactly matches what really
happened as closely as possible the first time through. If it
doesn't, we're pretty hosed.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, the other side of that argument is that changing these things in
>> the CVS repository will be overwriting the available evidence, in case
>> any questions come up later. On the git side, applying the tag to the
>> appropriate commit is an easy --- and easily changeable --- thing, isn't
>> it?

> You can apply the tag to any commit that you want easily enough, but
> you can't change even the least detail of the commit contents. So if
> it turns out that there's no commit that exactly matches the desired
> tag contents, then things get sticky. That's why we need to make sure
> that the reconstructed series of commits exactly matches what really
> happened as closely as possible the first time through. If it
> doesn't, we're pretty hosed.

I've already found the commits on the CVS side that I think ought to get
the tags --- that's what that "matches" file is about. If cvs2git can't
be trusted to duplicate those tree states then we have bigger problems.
Of course, now that I've got the tarballs I will be rechecking them
against git checkouts as part of the acceptance tests for the final
conversion, but right now I don't foresee a problem here.

regards, tom lane

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/

On Mon, Sep 13, 2010 at 18:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This is an attempt to sum up the open issues remaining before we can
> make another try at converting our source code to git.

<snip>

> * The REL8_0_0 branch needs to be downgraded to a tag, as previously
> discussed.

Yeah, and that's easily done.

> * There are several things we should do to make the manufactured commits
> less ugly, assuming we can't get rid of them entirely:
> ** Blame them on a nonexistent committer, probably "cvs2git" itself.

I've set the script onthe prod box up to blame it on cvs2git
<webmaster(at)postgresql(dot)org>
(same email address as the pgsql user, but different name)

> ** If we do that, I'm inclined to also blame the inserted dead .0
>   revisions on cvs2git.  Right now I copied-and-pasted the committer info
>   from the mainline commit they inherit from, which is not very relevant.

+1

> ** Make the manufactured-commit log messages say cvs2git not cvs2svn.

Done in my options file - it's just a couple of settings.

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

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> 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)

Could we see your full script and options file? I'm busy running test
conversions myself, and would like to be sure that I'm on the same page
as you are.

BTW, the conversion I'm getting at the moment (using the fixup script
I posted last night) does not have the weird "unlabeled" branches that
were complained of earlier. I think that nuking the WIN32_DEV derived
files probably was what stopped that.

regards, tom lane