On Sun, Sep 19, 2010 at 18:52, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 09/19/2010 12:25 PM, Tom Lane wrote:
# We don't want to change line numbers, so we simply reduce the keyword
# string to the file pathname part. For example,
# $PostgreSQL:
I wrote:
I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
with the proposed clean_keywords.pl script. I'd like it to reduce the
$PostgreSQL$ thingies to the full pathname of the file, rather than
try to remove all trace of them, eg
* $PostgreSQL:
On 09/19/2010 12:25 PM, Tom Lane wrote:
Pursuant to that, attached are proposed modified versions of the two
scripts involved.
#
# We don't want to change line numbers, so we simply reduce the keyword
# string to the file pathname part. For example,
# $PostgreSQL:
Andrew Dunstan and...@dunslane.net writes:
On 09/19/2010 12:25 PM, Tom Lane wrote:
# We don't want to change line numbers, so we simply reduce the keyword
# string to the file pathname part. For example,
# $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12 2010/09/07 14:10:30 momjian
Exp $
#
I wrote:
This commit occurred during that interval between where we'd initially
branched 7.3 and where we moved it up to head. I think what happened
was that I tried to back-patch a fix into what was then the 7.3 branch,
and when Marc moved the branch point, these commits all ended up
On Tue, Sep 14, 2010 at 12:01:18PM -0400, Tom Lane wrote:
Well ... I guess the other attitude we could take is that that was a
private development branch of Michael's. If we'd been working in git
Actually it wasn't. This branch was created when ecpg grew too big for the
released version of
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Attached is an updated repository.fixups script that inserts dead
revisions in every case where a new file was back-patched into an
existing branch. With that, we are down to a total of nine manufactured
commits, to wit:
Robert Haas robertmh...@gmail.com writes:
Magnus posted an updated conversion this morning.
http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
Evidently, however, he didn't do the same things you did, because
there are DEFINITELY more than 9 manufactured commits in this
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Magnus posted an updated conversion this morning.
http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
Evidently, however, he didn't do the same things you did,
On 09/17/2010 11:39 AM, Tom Lane wrote:
Is there any possibility that git clone isn't very trustworthy?
It's a bit scary that we don't see identical views of this repository.
I should have thought that very unlikely.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Magnus posted an updated conversion this morning.
Robert Haas robertmh...@gmail.com writes:
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
and I only see nine. It's got some *other* problems though; compared
to a conversion I just finished locally, it's missing a whole lot of
history for some of the old jdbc files.
On Fri, Sep 17, 2010 at 18:28, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Magnus posted an updated conversion
Magnus Hagander mag...@hagander.net writes:
On Fri, Sep 17, 2010 at 18:28, Robert Haas robertmh...@gmail.com wrote:
Sorry, I must not have cleaned out the old state properly.
Turns out I did th esame thing from my box to the repo on git.postgresql.org.
So I've now wiped that repository and
On Fri, Sep 17, 2010 at 19:20, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Sep 17, 2010 at 18:28, Robert Haas robertmh...@gmail.com wrote:
Sorry, I must not have cleaned out the old state properly.
Turns out I did th esame thing from my box to the
Magnus Hagander mag...@hagander.net writes:
Just to confirm, you ran your patch against current cvs, right? So you
also got the hunk succeeded at offset 1 line a whole bunch of times?
Then it's not that that's broken.
Right, the patch still applies fine, it's just off by a line or so in
many
I wrote:
Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
and tar'd up the /cvsroot directory ;-). I wonder if there's something
wrong with the anoncvs copy of that subdirectory? Will do the rsync
and compare.
Doh:
Only in myrepo/pgsql/contrib/retep/uk/org/retep/xml:
On Fri, Sep 17, 2010 at 20:24, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
and tar'd up the /cvsroot directory ;-). I wonder if there's something
wrong with the anoncvs copy of that subdirectory? Will do the rsync
and
I wrote:
Something in the rsync process thinks that ignoring subdirectories
named core is a good idea. I'm a bit surprised nobody ever noticed
these were missing from anoncvs before ...
That's because they aren't. It's the -C switch in your rsync call
that's at fault. (And this demonstrates
On Fri, Sep 17, 2010 at 20:32, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Something in the rsync process thinks that ignoring subdirectories
named core is a good idea. I'm a bit surprised nobody ever noticed
these were missing from anoncvs before ...
That's because they aren't. It's the
I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
with the proposed clean_keywords.pl script. I'd like it to reduce the
$PostgreSQL$ thingies to the full pathname of the file, rather than
try to remove all trace of them, eg
*$PostgreSQL: pgsql/src/port/unsetenv.c,v
On 09/17/2010 02:37 PM, Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 20:32, Tom Lanet...@sss.pgh.pa.us wrote:
I wrote:
Something in the rsync process thinks that ignoring subdirectories
named core is a good idea. I'm a bit surprised nobody ever noticed
these were missing from anoncvs
On Fri, Sep 17, 2010 at 20:49, Tom Lane t...@sss.pgh.pa.us wrote:
I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
with the proposed clean_keywords.pl script. I'd like it to reduce the
$PostgreSQL$ thingies to the full pathname of the file, rather than
try to remove
Magnus Hagander mag...@hagander.net writes:
Will not doing the backbranches make it harder to backport patches?
Probably shouldn't, unless you're changing the very first line of the
file, right?
The $PostgreSQL$ lines haven't been a backporting problem in the past,
so I don't see why they'd be
On Fri, Sep 17, 2010 at 20:37, Magnus Hagander mag...@hagander.net wrote:
On Fri, Sep 17, 2010 at 20:32, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Something in the rsync process thinks that ignoring subdirectories
named core is a good idea. I'm a bit surprised nobody ever noticed
these
BTW, on the cleanup steps:
# Remove bogus branches
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D unlabeled-1.87.2
git branch -D unlabeled-1.90.2
You should not need any of the above; I don't see those being generated
anymore with the
I wrote:
In addition to the above, we're going to want to clean up the
Release_2_0_0 and Release_2_0 tags, but I'm not sure if there's
a reasonable way to script those when the commit SHA1's aren't frozen
yet. I can give you timestamps for the commits they should point at,
but I lack the
On Fri, Sep 17, 2010 at 23:01, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, on the cleanup steps:
# Remove bogus branches
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D unlabeled-1.87.2
git branch -D unlabeled-1.90.2
You should not
On Fri, Sep 17, 2010 at 23:21, Tom Lane t...@sss.pgh.pa.us wrote:
Actually, the simplest way to handle this might be to just delete all
five of those tags during the conversion, and then I'll put them back
in the right places later when I add the other old-release tags.
That way we won't have
Magnus Hagander mag...@hagander.net writes:
On Fri, Sep 17, 2010 at 23:01, Tom Lane t...@sss.pgh.pa.us wrote:
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D unlabeled-1.87.2
git branch -D unlabeled-1.90.2
You should not need any
On Sat, Sep 18, 2010 at 00:06, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Sep 17, 2010 at 23:01, Tom Lane t...@sss.pgh.pa.us wrote:
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D
Magnus Hagander mag...@hagander.net writes:
On Sat, Sep 18, 2010 at 00:06, Tom Lane t...@sss.pgh.pa.us wrote:
[ scratches head ... ] That's weird. We probably ought to figure out
why you and I are getting different results. I wonder if there's some
other discrepancy in the anoncvs pull?
I wrote:
Oh, mystery explained upon comparing the cvs2git.options files.
I was using Max's file which had this in it:
ExcludeRegexpStrategyRule(r'unlabeled-.*'),
I think I'll rerun without that just to convince myself of what it is
we're dropping. But right now it seems that everything
Tom Lane t...@sss.pgh.pa.us writes:
PS: This attachment is text/x-patch instead of text/plain ... does
it come through as an attachment for you, Robert?
From my MUA, I can say that it's not so much a problem of MIME type than
the Content-Disposition, yours are always inline.
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
* Four that create the partial tags SUPPORT, MANUAL_1_0, creation, and
Release-1-6-0. I think we agreed that we can just drop these tags and
allow their manufactured commits to be garbage-collected.
+1.
* Two that create
Robert Haas robertmh...@gmail.com writes:
Incidentally, with respect to timing, do we want to press on with this
conversion now or wait until after the CommitFest is done?
I'd kind of like to do it before we start the commitfest. These
repository patches will go stale if we wait too long, and
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
* One that creates the partial branch ecpg_big_bison. I think we have
to live with this too. I don't want to drop the branch altogether,
as that would represent a loss of
Excerpts from Dimitri Fontaine's message of mar sep 14 11:10:50 -0400 2010:
Tom Lane t...@sss.pgh.pa.us writes:
PS: This attachment is text/x-patch instead of text/plain ... does
it come through as an attachment for you, Robert?
From my MUA, I can say that it's not so much a problem of
On Tue, Sep 14, 2010 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane t...@sss.pgh.pa.us wrote:
* One that creates the partial branch ecpg_big_bison. I think we have
to live with this too. I don't want to
Robert Haas robertmh...@gmail.com writes:
We're not planning to delete the CVS repository, are we?
Not in the short term, but I'd like to think that the git repository
will contain everything of conceivable interest.
regards, tom lane
--
Sent via pgsql-hackers mailing
On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We're not planning to delete the CVS repository, are we?
Not in the short term, but I'd like to think that the git repository
will contain everything of conceivable interest.
Hmm,
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
We're not planning to delete the CVS repository, are we?
Not in the short term, but I'd like to think that the git repository
will contain
Excerpts from Tom Lane's message of mar sep 14 12:45:28 -0400 2010:
I want a good, clean, complete history in git, but ancient partial
branches are below my threshold for caring. But if you feel it's
useful, we can keep the tag - I don't care enough to argue about it.
... but having
Alvaro Herrera alvhe...@commandprompt.com writes:
I think there's hardly much of interest in that branch, so it doesn't
make sense to waste too much effort on it. However, why would we delete
it? Just keep it with the manufactured tag and all -- so it is there,
even if the history is not all
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've spent much of the weekend examining the discrepancies between our CVS
repository and the tarballs available from our FTP archives, and after
that trying to remove infelicities in the cvs2git output. There are a
couple
Robert Haas robertmh...@gmail.com writes:
Regrettably, all of your attachments came through as part of the
actual email, both in my GMail and in the archives. I hate
technology.
Sorry about that. Here's another try with the stuff in a tarball.
This time, I also remembered to include
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Having completed that comparison, I then moved on to trying to get rid of
the discrepancies in the git conversion; particularly, trying to get rid
of the manufactured commits. I
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Having completed that comparison, I then moved on to trying to get rid of
the discrepancies in the git conversion;
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder if we should consider fixing some or all of these things on
the master CVS repository. I wouldn't be too eager to inject those
On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder if we should consider fixing some or all of these things on
the
I wrote:
I'm a bit disappointed by the fact that we get either of these. I had
gathered from Max's comments that the dead-revision-at-the-base-of-the-
branch trick is considered standard in newer CVS versions, and so I'd
hoped that cvs2git would understand the construct and not generate
I wrote:
return bool(re.match(
r'file .* was added on branch .* on '
r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
'\n$',
log_msg,
))
So it looks like I have to make the dead revisions' log messages match
that regexp. Off to make
On Mon, Sep 13, 2010 at 21:28, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
return bool(re.match(
r'file .* was added on branch .* on '
r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
'\n$',
log_msg,
))
So it looks like I have to make
Tom Lane wrote:
the tarball was actually made. In particular, the tags REL6_5, REL7_1,
and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
lot of faith in some of the other early tags either, because we don't seem
to have an archived tarball to compare them to.
I
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
the tarball was actually made. In particular, the tags REL6_5, REL7_1,
and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
lot of faith in some of the other early tags either, because we don't seem
to have an
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
the tarball was actually made. In particular, the tags REL6_5, REL7_1,
and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
lot of faith in some of the other early tags either, because we don't
56 matches
Mail list logo
