Git conversion status
Hi!
CVS has been frozen, and all commit access locked out.
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)
So I've moved it in place. It's on
http://git.postgresql.org/gitweb?p=postgresql-migration.git. Git
access available at
git://git.postgresql.org/git/postgresql-migration.git.
Committers can (and should! please test!) clone from git clone
ssh://git@gitmaster.postgresql.org/postgresql.git.
Please do *NOT* commit or push anything to this repository yet though:
The repo is there - all the scripts to manage it are *not*. So don't
commit until I confirm that it is.
But please clone and verify the stuff we have now.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander wrote:
Hi!
CVS has been frozen, and all commit access locked out.
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)So I've moved it in place. It's on
http://git.postgresql.org/gitweb?p=postgresql-migration.git. Git
access available at
git://git.postgresql.org/git/postgresql-migration.git.Committers can (and should! please test!) clone from git clone
ssh://git@gitmaster.postgresql.org/postgresql.git.Please do *NOT* commit or push anything to this repository yet though:
The repo is there - all the scripts to manage it are *not*. So don't
commit until I confirm that it is.But please clone and verify the stuff we have now.
Git clone worked just fine.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Magnus Hagander <magnus@hagander.net> writes:
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)
This is not even close to matching the tarballs :-(. Seems to be a
locale problem: the diffs look like
1c1
< /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05 18:25:16 tgl Exp $ */
---
/* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */
Please fix and re-run.
regards, tom lane
On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)This is not even close to matching the tarballs :-(. Seems to be a
locale problem: the diffs look like1c1
< /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05 18:25:16 tgl Exp $ */
---/* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */
Please fix and re-run.
Uh, what the heck. I ran the exact same command as last time.. Hmm:
Stefan rbeooted the machine in between, I wonder if that changed
something.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same command as last time.. Hmm:
Stefan rbeooted the machine in between, I wonder if that changed
something.
I'm not sure we ever checked that. My comparisons against the tarballs
were done from my own run of the conversion script. I'm using C locale
here, probably you aren't?
regards, tom lane
On Mon, Sep 20, 2010 at 19:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same command as last time.. Hmm:
Stefan rbeooted the machine in between, I wonder if that changed
something.I'm not sure we ever checked that. My comparisons against the tarballs
were done from my own run of the conversion script. I'm using C locale
here, probably you aren't?
Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see
exaclty what changes.
Hmm
Nope, doesn't seem to change. I just set my LANG=C, and ran a "cvs
export". but it comes back with "-" in the dates, so it seems to not
care about that.
("locale" clearly shows it's changed everything to C though)
Is there a cvs setting for this somewhere that you know of?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see
exaclty what changes.
Hmm
Nope, doesn't seem to change. I just set my LANG=C, and ran a "cvs
export". but it comes back with "-" in the dates, so it seems to not
care about that.
I thought "cvs export" removed keywords entirely ... try a checkout
instead. Also, are you sure you don't have any LC_xxx variables set?
regards, tom lane
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Mon, Sep 20, 2010 at 19:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same command as last time.. Hmm:
Stefan rbeooted the machine in between, I wonder if that changed
something.I'm not sure we ever checked that. My comparisons against the tarballs
were done from my own run of the conversion script. I'm using C locale
here, probably you aren't?Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see exaclty what changes.
HmmNope, doesn't seem to change. I just set my LANG=C, and ran a "cvs export". but it comes back with "-" in the dates, so it seems to not care about that.
("locale" clearly shows it's changed everything to C though)
Is there a cvs setting for this somewhere that you know of?
Think I found it.
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
debian applies a patch to change it.
[ rolls eyes... ] Thank you, debian.
regards, tom lane
On Mon, Sep 20, 2010 at 20:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
debian applies a patch to change it.
[ rolls eyes... ] Thank you, debian.
Indeed.
For the archives, that's DateFormat=old, not DateStyle. Oops.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander<magnus@hagander.net> wrote:
On Mon, Sep 20, 2010 at 19:49, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Magnus Hagander<magnus@hagander.net> writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same command as last time.. Hmm:
Stefan rbeooted the machine in between, I wonder if that changed
something.I'm not sure we ever checked that. My comparisons against the tarballs
were done from my own run of the conversion script. I'm using C locale
here, probably you aren't?Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see exaclty what changes.
HmmNope, doesn't seem to change. I just set my LANG=C, and ran a "cvs export". but it comes back with "-" in the dates, so it seems to not care about that.
("locale" clearly shows it's changed everything to C though)
Is there a cvs setting for this somewhere that you know of?
Think I found it.
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.
actually as I understand it the behaviour changed in cvs 1.12.x and
debian applied a patch to provide the old output for backwards
compatibility...
Stefan
BTW, while poking around in this morning's attempt I noticed
.git/description, containing
Unnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to stick
something in there.
regards, tom lane
On Monday 20 September 2010 20:15:50 Tom Lane wrote:
BTW, while poking around in this morning's attempt I noticed
.git/description, containingUnnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to stick
something in there.
Its mostly used for display in gitweb and can be changed anytime.
Andres
On Mon, Sep 20, 2010 at 20:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
BTW, while poking around in this morning's attempt I noticed
.git/description, containingUnnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to stick
something in there.
That's, AFAIK, only used for gitweb.
That said, where was it set to that? A locally initialized repo, or on
the clone? Because I changed it in the repository before I published
it I think (i now deleted the whole repo to make room for the new
conversion, so i can't doublecheck that :D)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.
actually as I understand it the behaviour changed in cvs 1.12.x and
debian applied a patch to provide the old output for backwards
compatibility...
Well, I'm testing with an unmodified copy of 1.12.13, and I got output
matching our historical tarballs. So I'm blaming debian for this one.
regards, tom lane
Andres Freund <andres@anarazel.de> writes:
On Monday 20 September 2010 20:15:50 Tom Lane wrote:
BTW, while poking around in this morning's attempt I noticed
.git/description, containingUnnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to stick
something in there.
Its mostly used for display in gitweb and can be changed anytime.
Hm, I might've misinterpreted its semantics. Is that file copied by
"git clone", or is it something that's unique to each physical
repository?
regards, tom lane
Magnus Hagander <magnus@hagander.net> writes:
On Mon, Sep 20, 2010 at 20:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
BTW, while poking around in this morning's attempt I noticed
.git/description, containingUnnamed repository; edit this file 'description' to name the repository.
That said, where was it set to that? A locally initialized repo, or on
the clone?
That's what I found in the result of
git clone ssh://git@gitmaster.postgresql.org/postgresql.git
If git clone isn't meant to copy it, then this is a non-issue.
regards, tom lane
On Monday 20 September 2010 20:22:55 Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On Monday 20 September 2010 20:15:50 Tom Lane wrote:
BTW, while poking around in this morning's attempt I noticed
.git/description, containingUnnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to stick
something in there.Its mostly used for display in gitweb and can be changed anytime.
Hm, I might've misinterpreted its semantics. Is that file copied by
"git clone", or is it something that's unique to each physical
repository?
Unique to each "physical repository" (like everything in .git - unless you
count the cloned 'objects').
Andres
On 09/20/2010 08:21 PM, Tom Lane wrote:
Stefan Kaltenbrunner<stefan@kaltenbrunner.cc> writes:
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.actually as I understand it the behaviour changed in cvs 1.12.x and
debian applied a patch to provide the old output for backwards
compatibility...Well, I'm testing with an unmodified copy of 1.12.13, and I got output
matching our historical tarballs. So I'm blaming debian for this one.
not sure - if I read the CVS changelog the "new style" output only
triggers if both the server AND the client are > 1.12.x (for some value
of x on both).
As far as I know magnus is using a debian based CVS server for his
testing so that would certainly be 1.12.x - are you too?
Stefan
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
On 09/20/2010 08:21 PM, Tom Lane wrote:
Well, I'm testing with an unmodified copy of 1.12.13, and I got output
matching our historical tarballs. So I'm blaming debian for this one.
As far as I know magnus is using a debian based CVS server for his
testing so that would certainly be 1.12.x - are you too?
No server anywhere: I'm reading from a local repository which is a
tarball copy of the one on cvs.postgresql.org. 1.12.13 is the only
version in question. (I believe Magnus is not using a server either;
the cvs2git documentation says that it will only work from a local repo,
and even if that's not true I shudder to think how long it would take
over a network.)
regards, tom lane