Hey Magnus, what exactly was your process for verifying the file
contents of the various release tags in the git conversion? Did
you check them against the published tarballs, or against what the
CVS repository said they should be? Because I've just found that
this odd-looking manufactured commit:
commit 94b87adc86f5dce6ee5957af83c41fa1f8476c39 refs/tags/REL7_3_5
Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
Date: Tue Dec 2 16:26:01 2003 +0000
This commit was manufactured by cvs2svn to create tag 'REL7_3_5'.
Sprout from REL7_3_STABLE 2003-12-02 16:26:00 UTC Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 'Brand 7.3.5.'
is there because these files have no REL7_3_5 tag according to CVS.
Which is damn weird, because they all have tags for the preceding
and following releases, *and they are there in the published tarball*.
It looks to me like what didn't get tagged is a few complete
directories, which means the most likely mechanism is the "cvs tag"
operation being run in a checkout tree that lacked these subdirectories
for some reason. But that's just a guess; we'll probably never know
Anyway I am now thinking that we'd better compare published tarballs to
the CVS tags and find out what other discrepancies there are. The
checking we've done to verify releases in the past has always been that
the tarballs were sane, not that the tagging was sane, so in case of any
discrepancy I'd say the tarball should be considered authoritative.
I've already found one other issue: the root HISTORY and INSTALL files
have REL7_3_10 tags and should not. This is not entirely CVS' fault
though: I think what happened is that Marc manually moved the
already-applied REL7_3_10 tag when we re-did that release, and didn't
account for the fact that I'd deleted those two files in the branch
meanwhile. That one is also confusing cvs2git no end.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2010-09-10 07:45:00|
|Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing
|Previous:||From: Darren Duncan||Date: 2010-09-10 05:02:14|
|Subject: Re: returning multiple result sets from a stored procedure|