Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
