Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> These files are generated (from gram.y, pgc.l and preproc.y
>> respectievly) and are not present in the CVS repo, though I think they
>> have been at some point.
>
>> It's strange that other generated files (that have also been in the repo
>> in the past) like preproc.h are not showing up.
>
> The weird thing about these files is that the CVS history shows commits
> on HEAD later than the file removal commit. I don't recall if Vadim
> unintentionally re-added the files before making those commits ... but
> if he did, you'd think it'd have taken another explicit removal to get
> rid of them in HEAD. More likely, there was some problem in his local
> tree that allowed a "cvs commit" to think it should update the
> repository with copies of the derived files he happened to have.
>
> I think this is a corner case that CVS handles in a particular way and
> the tools people are using to read the repository handle in a different
> way. Which would be a bug in those tools, since CVS's interpretation
> must be right by definition.
The question is if it'd be acceptable to manually remove that last commit
from the repository. I guess simply readding, and then removing the files
again should do the trick, though I'd be cleaner to fix remove the
offending commit in the first place. Should postgres ever decide to switch
to another version control system (which I don't advocate), that'd be
one obstacle less to deal with...
Or is the risk of causing breakage too high?
greetings, Florian Pflug