Re: git: uh-oh

On 25/08/10 04:21, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:

> What seemed more likely to be artifacts were
> these:
>
> remotes/origin/unlabeled-1.44.2
> remotes/origin/unlabeled-1.51.2
> remotes/origin/unlabeled-1.59.2
> remotes/origin/unlabeled-1.87.2
> remotes/origin/unlabeled-1.90.2
>
> Any idea where those came from?

These occur when there are numbered revisions in one or more RCS files,
which lack a branch tag to identify their name. The most likely cause is
deleting a branch after having committed to it.

Indeed, all of these five correspond to a commit with the message:

Make the world at least somewhat safe for zero-column tables, and
remove the special case in ALTER DROP COLUMN to prohibit dropping a
table's last column.

I have an idea you can fix this by running the following on your live
CVS repository:

cvs rtag -D "2002-09-23 20:43:41 UTC" zero-column-tables pgsql
cvs rtag -F -B -r 1.44.2 zero-column-tables \
pgsql/src/backend/commands/tablecmds.c
cvs rtag -F -B -r 1.90.2 zero-column-tables \
pgsql/src/backend/parser/parse_target.c
cvs rtag -F -B -r 1.90.2 zero-column-tables \
pgsql/src/backend/access/common/tupdesc.c
cvs rtag -F -B -r 1.59.2 zero-column-tables \
pgsql/src/backend/executor/execTuples.c
cvs rtag -F -B -r 1.87.2 zero-column-tables \
pgsql/src/backend/executor/nodeAgg.c,v
cvs rtag -F -B -r 1.51.2 zero-column-tables \
pgsql/src/test/regress/expected/alter_table.out

(Untested as yet, I have a test conversion running.)

>> This series of commits also seems pretty messed up:
>> http://archives.postgresql.org/pgsql-committers/2007-04/msg00222.php
>> http://archives.postgresql.org/pgsql-committers/2007-04/msg00223.php
>
> You can find out about the reasons for that in this *other* discussion
> of conversion to git:
> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00670.php
> particularly here:
> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00685.php
>
>> ... pretty crazy. I think we should try to do something to clean this up,
>> perhaps by doctoring the file on the CVS side.
>
> On the whole I feel that you're moving the goalposts. AFAIR the agreed
> criteria for an acceptable SCM conversion were that it reproduce the
> historical states of our tree at least at all the release tags, and that
> it provide a close approximation of the CVS commit logs. I think that
> manufactured commits that correspond to CVS's artifacts might be a bit
> ugly, but trying to get rid of them sounds way too much like putting
> lipstick on a pig. And if it means removing real, if ugly, history,
> I'm not sure I'm in favor of it at all.

I'm mostly with Tom on this one. Basically you are now discovering what
a mess CVS has made. The mess has always existed, but only now do you
have the tools to notice this.

Your options are:

1) Accept that.

2) Retroactively modify history to say that those generated files NEVER
existed in the repository.

3) Retroactively modify history to say that those generated files are
actually included in all those release tags.

Max.