Magnus Hagander wrote:
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan <and...@dunslane.net> wrote:
Kevin Grittner wrote:
The reported source of the software seems to have gone away. I can
let you have my copy, which reliably reproduces the error, so we
have a good failure test case.
If it's not as recent as this:
http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132
we might want to bring in (or at least review) what's been committed
since we grabbed our copy. Some of the fixes mentioned sound like
they might possibly be related.
OK, there is good news on this front. When last I looked this repo was
giving errors, so I worked from the copy of the code I already had. (So
thanks to Kevin for prodding me to check again.) With the latest fromcvs and
rcsparse packages downloaded from this site I can now make and run the 7.4
and 8.1 branches from the imported repository (I haven't checked other
branches yet.)
What exactly did you test? Did you run it from scratch, or did you run
it on top of the existing git repo? Because AFAIK the bug isn't
consisten in that if you just do a fresh migration, it often works -
even with the current version we have deployed. I haven't checked that
in detail though - was this included in your tests?
On the version of the code I was using was fetched from the Mercurial
repo. The versions I originally tested with are
rcsparse-1a3116e80c2e and
fromcvs-186299486bdc.
The versions I have had success with are
rcsparse-75d93404707d and
fromcvs-c31a1dd9cbb2
On the older versions I tested, the errors appeared each time I ran the
initial imports on the CVS clone I was testing with. With the latest
version it has not.
So we need to look at how hard it would be to upgrade the scripts on
git.postgresql.org, and if by doing so we can fix its versions of the back
Upgrading the script is trivial. It's working off a git checkout with
a specific hash,iirc, because there were no actualstable releases at
the time, so if you can tell me which commit to check out, that's
easy.
Will this automatically fix the backbranches, or do we need to do
something more than just upgrading it?
I think what we'd need to do is remove the back branches that are
failing and let it reimport them completely. AFAIK this should work
without disturbing the branches we didn't remove. But it should be
tested rigorously before being tried.
branches. It would also be a good idea to have a script that regularly
checks out the important branches from git and checks that they are
identical to what is in CVS. That might help to increase Tom's confidence
level.
Yes, that would be very good. ISTR there's a script somewhere, but it
didn't run without showing some issues? Particularly related to the
keyword expansion stuff?
If someone has such a script ready today, it should be easy to deploy
it on the git server for regular checks. If not, volunteers are most
welcome to write one :-)
What I have done is to set up my own mirror and I will be testing it on
all the live branches with a git-ized buildfarm client.
I can probably pull together a script that exports from both git and cvs
and compares.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
