On Sun, Sep 19, 2010 at 18:52, Tom Lane wrote:
> Andrew Dunstan 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
Andrew Dunstan 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 $
>> # becomes
>>
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: pgsql/src/port/unsetenv.c
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: pgsql/src/p
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
> or
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 everythi
Magnus Hagander writes:
> On Sat, Sep 18, 2010 at 00:06, Tom Lane 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?
> Could be.
Oh, mystery explaine
On Sat, Sep 18, 2010 at 00:06, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Sep 17, 2010 at 23:01, Tom Lane 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.
Magnus Hagander writes:
> On Fri, Sep 17, 2010 at 23:01, Tom Lane 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 of the above; I don't s
On Fri, Sep 17, 2010 at 23:21, Tom Lane 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 any tags gettin
On Fri, Sep 17, 2010 at 23:01, Tom Lane 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 need any o
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
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 cl
On Fri, Sep 17, 2010 at 20:37, Magnus Hagander wrote:
> On Fri, Sep 17, 2010 at 20:32, Tom Lane 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 b
Magnus Hagander 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 one now.
On Fri, Sep 17, 2010 at 20:49, Tom Lane 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
On 09/17/2010 02:37 PM, Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 20:32, Tom Lane 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 b
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 Fri, Sep 17, 2010 at 20:32, Tom Lane 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 -C switch
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 demonstr
On Fri, Sep 17, 2010 at 20:24, Tom Lane 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 compare.
>
>
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/xm
Magnus Hagander 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 places (probably
On Fri, Sep 17, 2010 at 19:20, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Sep 17, 2010 at 18:28, Robert Haas 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 t
Magnus Hagander writes:
> On Fri, Sep 17, 2010 at 18:28, Robert Haas 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 re-pushed mine. Can you give it
> ano
On Fri, Sep 17, 2010 at 18:28, Robert Haas wrote:
> On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
>>> Robert Haas writes:
Magnus posted an updated conversion this morning.
>>>
http://git.postgresql.org/gitweb?p=postgresql-mig
Robert Haas writes:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane 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.
> What's the problem with the ol
On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Magnus posted an updated conversion this morning.
>>
>>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>>
>>> Evidently, however, he didn't
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 (pgsql-hackers@p
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
> Robert Haas 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 mo
Robert Haas 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 one.
Um ... I just
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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:
> [details]
Magnu
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 bi
Alvaro Herrera 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 that clean. This _is_
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 hav
Robert Haas writes:
> On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
>> Robert Haas 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, OK.
On Tue, Sep 14, 2010 at 12:23 PM, Tom Lane wrote:
> Robert Haas 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, OK. That's never really been one o
Robert Haas 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 list (pgsql-hackers@p
On Tue, Sep 14, 2010 at 12:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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 repres
Excerpts from Dimitri Fontaine's message of mar sep 14 11:10:50 -0400 2010:
> Tom Lane 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
Robert Haas writes:
> On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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 development history. The only other
>> alt
Robert Haas 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 a month
is probably
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane 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 the tags Release
Tom Lane 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.
http://www.gnus.org/manual/emacs
Tom Lane wrote:
> Bruce Momjian 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
>
Bruce Momjian 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 archived tarb
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 be
On Mon, Sep 13, 2010 at 21:28, Tom Lane 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 the
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
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
>
On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
>>> Robert Haas 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
Robert Haas writes:
> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
>> Robert Haas 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
>>> fake .0 commits for fear of breakage, but moving tag
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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 "manu
Robert Haas writes:
> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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 didn't have much success in that fo
Robert Haas 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 cvs2git.options; although
I
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane 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 of remaining odd
56 matches
Mail list logo
