Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie sep 10 12:17:30 -0400 2010:
>> This is 1.11.23, so it's certainly not older than our server.
> Hmm, I have 1.12.13 here and it works for me.
Yeah ... what we actually have on the master server is 1.11.17-FreeBSD,
and it seems after
Excerpts from Alvaro Herrera's message of vie sep 10 12:51:26 -0400 2010:
> Hmm, I have 1.12.13 here and it works for me.
>
> I see that CVSROOT/config used to have the same lines:
>
> LocalKeyword=PostgreSQL=CVSHeader
> KeywordExpand=iPostgreSQL
>
> but now they are in the "config.bak" file.
Excerpts from Tom Lane's message of vie sep 10 12:17:30 -0400 2010:
> Alvaro Herrera writes:
> > I think older CVS versions used
> > tagexpand=iPostgreSQL
> > instead.
>
> This is 1.11.23, so it's certainly not older than our server.
Hmm, I have 1.12.13 here and it works for me.
I see that CVS
On Fri, Sep 10, 2010 at 18:17, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010:
>>> I'm trying to check the tarballs here, and I've run into the problem
>>> that my local copy of cvs doesn't know to expand the $PostgreSQL$
>>> keyword
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010:
>> I'm trying to check the tarballs here, and I've run into the problem
>> that my local copy of cvs doesn't know to expand the $PostgreSQL$
>> keywords. Where does one set that?
> CVSROOT/options, add a
Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010:
> I'm trying to check the tarballs here, and I've run into the problem
> that my local copy of cvs doesn't know to expand the $PostgreSQL$
> keywords. Where does one set that?
CVSROOT/options, add a line
tag=PostgreSQL=CVSHeade
Magnus Hagander writes:
> On Fri, Sep 10, 2010 at 07:51, Tom Lane wrote:
>> 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
Magnus Hagander writes:
> Anyway, yeah, it does seem like a good way to do it. If we can produce
> a patch that we apply to the raw cvs repository before we do the
> migration, that's good - but I would like to avoid the manual steps in
> the *actual migration*. Once we do the final migration, it
2010/9/10 Tom Lane :
> I wrote:
>> OK, so I tried a conversion with the it.po hack I showed before; not
>> trying to fix any of the other instances yet, but just see what happens
>> with the 8.4.3/8.4.4 case. It's definitely better:
>
>> * Marc's 8.4.3 tag commit is now the last ancestor of REL8_4
On Fri, Sep 10, 2010 at 07:51, Tom Lane wrote:
> 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
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
OK, so I tried a conversion with the it.po hack I showed before; not
trying to fix any of the other instances yet, but just see what happens
with the 8.4.3/8.4.4 case. It's definitely better:
* Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the
previous commits in the branch ar
On Wed, Sep 8, 2010 at 20:11, Tom Lane wrote:
> Magnus Hagander writes:
I'm using svn trunk revision 5244 from
http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
>
> Just to make sure everybody is on the same page: I've installed svn
> revision 5270, which is the version currently available f
Magnus Hagander writes:
>>> I'm using svn trunk revision 5244 from
>>> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
Just to make sure everybody is on the same page: I've installed svn
revision 5270, which is the version currently available from that URL,
and is also what Max indicated he was usin
On Wed, Sep 8, 2010 at 16:44, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
>>> Where can I find the version of cvs2git we're using?
>
>> I'm using svn trunk revision 5244 from
>> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
>
> [ blink... ] That URL
Magnus Hagander writes:
> On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
>> Where can I find the version of cvs2git we're using?
> I'm using svn trunk revision 5244 from
> http://cvs2svn.tigris.org/svn/cvs2svn/trunk.
[ blink... ] That URL seems to want a password.
regar
On Wed, Sep 8, 2010 at 16:21, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> Well, even if the goal is to faithfully represent the bogus history
>>> shown by CVS, cvs2git isn't doing a good job of it.
>
>> Them's fightin' words :-)
>
> Yeah ;-), but they were mainly directed at
Michael Haggerty writes:
> Tom Lane wrote:
>> Well, even if the goal is to faithfully represent the bogus history
>> shown by CVS, cvs2git isn't doing a good job of it.
> Them's fightin' words :-)
Yeah ;-), but they were mainly directed at Robert, who AIUI was
asserting that the behavior of "cvs
Tom Lane wrote:
> Well, even if the goal is to faithfully represent the bogus history
> shown by CVS, cvs2git isn't doing a good job of it.
Them's fightin' words :-)
> In the case of
> src/bin/pg_dump/po/it.po, the CVS history claims that the version
> added to REL8_4_STABLE on 2010-05-13 is a ch
Max Bowsher writes:
> On 08/09/10 00:37, Robert Haas wrote:
>> but if our CVS repository is busted maybe
>> we should be looking to fix that rather than complaining about
>> cvs2git.
> A possibility. We'd need a tool which would insert an extra node into
> the history graph of an RCS file. Unless
On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane wrote:
> Max Bowsher writes:
>> On 08/09/10 00:37, Robert Haas wrote:
>>> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
>>> see it in the NEWS file) and that a checkout-by-date shows the file
>>> present during the time cvs2git cla
Max Bowsher writes:
> On 08/09/10 00:37, Robert Haas wrote:
>> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
>> see it in the NEWS file) and that a checkout-by-date shows the file
>> present during the time cvs2git claims it is present, then a less
>> surprising translatio
Max Bowsher writes:
> On 08/09/10 00:47, Tom Lane wrote:
>> Max Bowsher writes:
>>> And, I've just tracked down that this bug was apparently fixed in CVS
>>> 1.11.18, released November 2004.
>>
>> Hrm, what bug exactly? As far as I've gathered from the discussion,
>> this is a fundamental desig
On 08/09/10 00:37, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>>> fairly good argument for his position.
>>
>> I ha
On 08/09/10 00:47, Tom Lane wrote:
> Max Bowsher writes:
>> And, I've just tracked down that this bug was apparently fixed in CVS
>> 1.11.18, released November 2004.
>
> Hrm, what bug exactly? As far as I've gathered from the discussion,
> this is a fundamental design limitation of CVS, not a fi
Max Bowsher writes:
> And, I've just tracked down that this bug was apparently fixed in CVS
> 1.11.18, released November 2004.
Hrm, what bug exactly? As far as I've gathered from the discussion,
this is a fundamental design limitation of CVS, not a fixable bug.
regards,
On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>> fairly good argument for his position.
>
> I haven't tested, but if I understand what Max and
Robert Haas writes:
> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
> INTERMEDIATE_DATE apparently shows the file as being there, which is a
> fairly good argument for his position.
I haven't tested, but if I understand what Max and Michael are saying
about CVS, that operation would proba
On Tue, Sep 7, 2010 at 6:34 PM, Tom Lane wrote:
> Hmm. Some further looking in the git log output shows that that
> "manufactured commit" is actually the ONLY commit shown as being a
> predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is
> shown as reached from refs/tags/REL8_4_4.
Max Bowsher writes:
> Hmm. Now I'm speculating vaguely about how the cycle breaker could be
> convinced to break branch update commits into as many pieces as
> possible, instead of as few.
That same thought occurred to me. If it simply didn't aggregate, but
treated each such file separately, wou
On 07/09/10 23:34, Tom Lane wrote:
> No doubt. However, the facts on the ground are that it.po is provably
> not there in REL8_4_0, REL8_4_1, REL8_4_2, or REL8_4_3, and is there in
> REL8_4_4, and that no commit on the branch touched it before 2010-05-13
> (just before 8.4.4). I will be intereste
I wrote:
> Hmm. Some further looking in the git log output shows that that
> "manufactured commit" is actually the ONLY commit shown as being a
> predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is
> shown as reached from refs/tags/REL8_4_4. This is at the least pretty
> weird, an
On 07/09/10 23:20, Max Bowsher wrote:
> On 07/09/10 23:15, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>>> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
>>> but it sure
Robert Haas writes:
> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>> and not refs/tags/REL8_4_3?
> I think this is another result of the same basic problem. Since
> cvs2git thinks it.po was added to REL8_4_STABLE
On 07/09/10 23:15, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
>> but it sure looks wrong. (Magnus, did you check agains
On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane wrote:
> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
> but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?)
I think this is anot
On 07/09/10 21:25, Magnus Hagander wrote:
> On Tue, Sep 7, 2010 at 22:06, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
>>> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
You're saying you don't "require" a fix on the latest issue here? Or
should we
Max Bowsher writes:
> It wouldn't - except for the fact that cvs2git batches such manufactured
> commits such that there is no guarantee that a single manufactured
> commit pertains only to files in the commit immediately afterwards. For
> example, consider the it.po file in the commit referenced
On Tue, Sep 7, 2010 at 22:16, Tom Lane wrote:
> Robert Haas writes:
>> I just looked at your latest conversion (based on what Max did) and it
>> looks a lot better. I think, though, that we should re-remove these
>> branches:
>
>> origin/unlabeled-1.44.2
>> origin/unlabeled-1.51.2
>> origi
On Tue, Sep 7, 2010 at 22:06, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
>>> You're saying you don't "require" a fix on the latest issue here? Or
>>> should we spend some time trying to figure out if we can f
Robert Haas writes:
> I just looked at your latest conversion (based on what Max did) and it
> looks a lot better. I think, though, that we should re-remove these
> branches:
> origin/unlabeled-1.44.2
> origin/unlabeled-1.51.2
> origin/unlabeled-1.59.2
> origin/unlabeled-1.87.2
> origi
On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
>> You're saying you don't "require" a fix on the latest issue here? Or
>> should we spend some time trying to figure out if we can fix it with
>> git-filter-branch?
>
> I think that "the
Max Bowsher writes:
> On 07/09/10 18:16, Tom Lane wrote:
>> Hmm, I see. This depends on the fact that git commits reference
>> filesystem states and not deltas, correct? So it does actually make
>> sense to just delete that commit from the history. I was concerned
>> that it'd invalidate later
On 07/09/10 18:16, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> What I'd like is for those commits to vanish from the git log entirely.
>
>> It seems to me that in your case such commits could be "grafted over":
>
>> *---*---*---*
>> \
>> A---B---C---D
>
Michael Haggerty writes:
> Tom Lane wrote:
>> What I'd like is for those commits to vanish from the git log entirely.
> It seems to me that in your case such commits could be "grafted over":
> *---*---*---*
> \
> A---B---C---D
> E.g., if "C" is one of these special manufactur
Max Bowsher writes:
> On 07/09/10 16:47, Tom Lane wrote:
>> Max Bowsher writes:
>>> ... Just as soon as I can figure out how
>>> to cleanly fit that into cvs2git's structure, I want it to change the
>>> word "create" to "update" in most of those commits.
>> I thought all of those message texts w
Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>>> Look for
>>>This commit was manufactured by cvs2svn to create branch ...
>
>> Ok, found a bunch of those (78 to be exact). And the issue with them
>> is we want to change the commit author on t
On 07/09/10 16:47, Tom Lane wrote:
> Max Bowsher writes:
>> Personally, the idea of trying to use git-filter-branch to make what
>> cvs2git currently gives you more sensible scares me silly.
>
> I'm not excited about it either --- but if Magnus wants to experiment,
> no harm trying.
>
>> Another
I wrote:
> Magnus Hagander writes:
>> Ok, found a bunch of those (78 to be exact).
> What I'd like is for those commits to vanish from the git log entirely.
> In a practical sense, what you should probably do is for each file
> mentioned in such a commit, cause the file's addition to the branch
Max Bowsher writes:
> Personally, the idea of trying to use git-filter-branch to make what
> cvs2git currently gives you more sensible scares me silly.
I'm not excited about it either --- but if Magnus wants to experiment,
no harm trying.
> Another glitch that might be worth fixing before you co
On 07/09/10 16:21, Magnus Hagander wrote:
> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
If you want to try, and it doesn't take much time, go for it. I was
just saying I wouldn't complain if we decide to li
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>> Look for
>> This commit was manufactured by cvs2svn to create branch ...
> Ok, found a bunch of those (78 to be exact). And the issue with them
> is we want to change the commit author on them to be whomever made t
On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
>>> If you want to try, and it doesn't take much time, go for it. I was
>>> just saying I wouldn't complain if we decide to live with it as-is.
>
>> Ok. Do we have a way of i
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
>> If you want to try, and it doesn't take much time, go for it. I was
>> just saying I wouldn't complain if we decide to live with it as-is.
> Ok. Do we have a way of identifying them - e.g. is it all the commits
> with a
On Tue, Sep 7, 2010 at 16:16, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
>>> Michael Haggerty writes:
Somebody could use "git filter-branch" to make this change after the
conversion, but I can't estimate how much work it would be.
>>>
>>
Magnus Hagander writes:
> On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
>> Michael Haggerty writes:
>>> Somebody could use "git filter-branch" to make this change after the
>>> conversion, but I can't estimate how much work it would be.
>>
>> The conversion is already far better than I expected
On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander wrote:
> You're saying you don't "require" a fix on the latest issue here? Or
> should we spend some time trying to figure out if we can fix it with
> git-filter-branch?
I think that "the latest issue here" is the issue of how files get
added to bra
On Tue, Sep 7, 2010 at 15:53, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> So, if we're prepared to assert that we've never done that, could we
>>> have an option to cvs2git that is willing to use the first commit on
>>> a branch to represent the act of adding the file to the
Michael Haggerty writes:
> Tom Lane wrote:
>> So, if we're prepared to assert that we've never done that, could we
>> have an option to cvs2git that is willing to use the first commit on
>> a branch to represent the act of adding the file to the branch?
> I'm afraid this would be pretty far down
Tom Lane wrote:
> Michael Haggerty writes:
>> No, it is also possible to use "cvs tag -b REL8_4_STABLE filename". In
>> this case the file as it appears on the current branch is added to the
>> specified branch, but CVS records no commit, author, or timestamp.
>
> So, if we're prepared to assert
On Mon, Sep 06, 2010 at 05:41:06AM +0200, Michael Haggerty wrote:
> Tom Lane wrote:
> > Michael Haggerty writes:
> >> CVS does not record when a branch was created or by whom. If a
> >> git commit has to be created for such events, cvs2git attributes
> >> them to a configurable username, which Ma
Michael Haggerty writes:
> Tom Lane wrote:
>> Actually, no I don't see. That sort of history might be possible in
>> some SCMs, but how is it possible in CVS? The only way to get a file
>> into a back branch is "cvs add" then "cvs commit", and the commit is
>> recorded, even if the file exactly
Tom Lane wrote:
> I wrote:
>> Michael Haggerty writes:
>>> On the contrary, I prefer an obvious indication of "I don't know" to a
>>> value that might appear to be authoritative but is really just a guess.
>>> It could be that one user copied the file verbatim to the branch and a
>>> second user c
I wrote:
> Michael Haggerty writes:
>> On the contrary, I prefer an obvious indication of "I don't know" to a
>> value that might appear to be authoritative but is really just a guess.
>> It could be that one user copied the file verbatim to the branch and a
>> second user changed the file as part
Magnus Hagander writes:
> On Mon, Sep 6, 2010 at 15:37, Tom Lane wrote:
>> Uh, no, not so. Marc used to use that ID for commits related to
>> pushing new versions. It's been retired, but there's nothing un-real
>> about the commits under that ID. Please pick something else. I thought
>> the s
On Mon, Sep 6, 2010 at 15:37, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
>>> If we can set it to a value different from any actual committer name,
>>> that would be a good thing to do.
>
>> I intentionally picked the "pgsql" user because AFAIK that
Magnus Hagander writes:
> On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
>> If we can set it to a value different from any actual committer name,
>> that would be a good thing to do.
> I intentionally picked the "pgsql" user because AFAIK that's what
> we've been previously using for "commits tha
On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> I suspect what it's doing is attributing the branch creation to the user
>>> who makes the first commit on the branch for that file. In general I'd
>>> expect that to give a reasonable result --- bett
On Sun, Sep 5, 2010 at 04:55, Robert Haas wrote:
> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
and the result is that things are looking pretty clean :-)
>>>
>>> Hey, that's great. But I wonder why Magnus got a different result.
>>
>> This is the first time I've posted these incantat
On Sun, Sep 5, 2010 at 10:43, Max Bowsher wrote:
> On 05/09/10 03:55, Robert Haas wrote:
>> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
Can you post the repo you ended up with somewhere?
>>>
>>> Well, it's a Bazaar repository at the moment :-)
>>>
>>> But, I'll re-run it targetting gi
Michael Haggerty writes:
> Tom Lane wrote:
>> I suspect what it's doing is attributing the branch creation to the user
>> who makes the first commit on the branch for that file. In general I'd
>> expect that to give a reasonable result --- better than choosing a
>> guaranteed-to-be-wrong constant
Tom Lane wrote:
> Michael Haggerty writes:
>> CVS does not record when a branch was created or by whom. If a git
>> commit has to be created for such events, cvs2git attributes them to a
>> configurable username, which Max has set to be "pgsql". It chooses the
>> latest possible timestamp that i
Michael Haggerty writes:
> Tom Lane wrote:
>> [...] The only real gripe I can find to make is that in the cases where
>> a file is added to a back branch, the "manufactured" commit is
>> invariably blamed on committer "pgsql". Can't we arrange to blame it
>> on the person who actually added the f
Tom Lane wrote:
> Max Bowsher writes:
>> For both, see http://github.com/maxb
>
> [...] The only real gripe I can find to make is that in the cases where
> a file is added to a back branch, the "manufactured" commit is
> invariably blamed on committer "pgsql". Can't we arrange to blame it
> on t
Max Bowsher writes:
> On 05/09/10 03:55, Robert Haas wrote:
>>> Can you post the repo you ended up with somewhere?
> For both, see http://github.com/maxb
I took the trouble to run through a mechanical diff of this version's
REL8_3_STABLE log history versus what I get from cvs2cl. Several cvs2cl
On 05/09/10 03:55, Robert Haas wrote:
> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
>>> Can you post the repo you ended up with somewhere?
>>
>> Well, it's a Bazaar repository at the moment :-)
>>
>> But, I'll re-run it targetting git, and push it somewhere. github?
>> anywhere better?
>
>
On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
>>> and the result is that things are looking pretty clean :-)
>>
>> Hey, that's great. But I wonder why Magnus got a different result.
>
> This is the first time I've posted these incantations for excising the
> unwanted history, so he would not
Max Bowsher writes:
> I think we should start a git repository somewhere containing the
> precise conversion recipe - i.e.:
> * cvs2git options file
> * cvs2git invocation command line
> * all scripts that massage the CVS repository before conversion, or the
> Git repository afterwards
I dunn
On 04/09/10 12:24, Robert Haas wrote:
> On Sat, Sep 4, 2010 at 3:22 AM, Max Bowsher wrote:
>> and the result is that things are looking pretty clean :-)
>
> Hey, that's great. But I wonder why Magnus got a different result.
This is the first time I've posted these incantations for excising the
On Sat, Sep 4, 2010 at 3:22 AM, Max Bowsher wrote:
> and the result is that things are looking pretty clean :-)
Hey, that's great. But I wonder why Magnus got a different result.
Can you post the repo you ended up with somewhere?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
On 03/09/10 03:34, Max Bowsher wrote:
Robert Haas wrote:
> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
> wrote:
>> What weirdness, exactly, are you discussing now? I've lost track of
>> which problem(s) are still unresolved.
> Lots of commits that look like this:
>>
Max Bowsher wrote:
> On 02/09/10 16:44, Michael Haggerty wrote:
>> My understanding was that the problem is not that the branches are
>> created, but that they are created from a non-optimal starting point,
>> making it necessary for each of them to be doctored using a fixup
>> commit. Since the t
On 02/09/10 16:44, Michael Haggerty wrote:
> Max Bowsher wrote:
>> On 02/09/10 14:40, Michael Haggerty wrote:
>>> Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
wrote:
> What weirdness, exactly, are you discussing now? I've lost track of
> which problem(s)
Max Bowsher wrote:
> On 02/09/10 14:40, Michael Haggerty wrote:
>> Robert Haas wrote:
>>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
>>> wrote:
What weirdness, exactly, are you discussing now? I've lost track of
which problem(s) are still unresolved.
>>> Lots of commits that look
On 02/09/10 14:40, Michael Haggerty wrote:
> Robert Haas wrote:
>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
>> wrote:
>>> What weirdness, exactly, are you discussing now? I've lost track of
>>> which problem(s) are still unresolved.
>>
>> Lots of commits that look like this:
>>
>> commit
Robert Haas wrote:
> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty wrote:
>> What weirdness, exactly, are you discussing now? I've lost track of
>> which problem(s) are still unresolved.
>
> Lots of commits that look like this:
>
> commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb
> Author: Po
On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty wrote:
> Robert Haas wrote:
>> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
That definitely didn't fix it, although I'm not quite sure why. Can
you throw the modified CVS you ran this off of up somewhere I can
rsync it?
>>
Robert Haas wrote:
> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>> you throw the modified CVS you ran this off of up somewhere I can
>>> rsync it?
>> no rsync server on that box, but I put up a tarball for you at
On Thu, Sep 2, 2010 at 05:13, Robert Haas wrote:
> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>> you throw the modified CVS you ran this off of up somewhere I can
>>> rsync it?
>>
>> no rsync server on that box,
On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>> That definitely didn't fix it, although I'm not quite sure why. Can
>> you throw the modified CVS you ran this off of up somewhere I can
>> rsync it?
>
> no rsync server on that box, but I put up a tarball for you at
> http://www.hagander.
On Wed, Sep 1, 2010 at 02:33, Robert Haas wrote:
> On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander wrote:
>> On Tue, Aug 31, 2010 at 19:46, Magnus Hagander wrote:
>>> On Tue, Aug 31, 2010 at 19:44, Tom Lane wrote:
Magnus Hagander writes:
> Ok. I've got a new migration runinng. Here's
On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander wrote:
> On Tue, Aug 31, 2010 at 19:46, Magnus Hagander wrote:
>> On Tue, Aug 31, 2010 at 19:44, Tom Lane wrote:
>>> Magnus Hagander writes:
Ok. I've got a new migration runinng. Here's the revisions removed:
RCS file: /usr/local/cvsroo
On Tue, Aug 31, 2010 at 19:46, Magnus Hagander wrote:
> On Tue, Aug 31, 2010 at 19:44, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Ok. I've got a new migration runinng. Here's the revisions removed:
>>> RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v
>>> deleting revision
On Tue, Aug 31, 2010 at 19:44, Tom Lane wrote:
> Magnus Hagander writes:
>> Ok. I've got a new migration runinng. Here's the revisions removed:
>> RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v
>> deleting revision 2.88
>> RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ec
Magnus Hagander writes:
> Ok. I've got a new migration runinng. Here's the revisions removed:
> RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v
> deleting revision 2.88
> RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v
> deleting revision 1.2
> RCS
On Tue, Aug 31, 2010 at 17:12, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 30, 2010 at 05:03, Robert Haas wrote:
cvs admin -o ?
>>>
>>> Magnus, is this something that you can try? Prune those could of
>>> wonky revisions after the delete and before the re-add prior to
>>> runn
Magnus Hagander writes:
> On Mon, Aug 30, 2010 at 05:03, Robert Haas wrote:
>>> cvs admin -o ?
>>
>> Magnus, is this something that you can try? Prune those could of
>> wonky revisions after the delete and before the re-add prior to
>> running the conversion, and see how that comes out?
> Yes,
On Mon, Aug 30, 2010 at 05:03, Robert Haas wrote:
> On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas wrote:
>> On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane wrote:
>>> Robert Haas writes:
The fact that the file was "modified" twice after being removed at rev
2.88 seems really wacko. Are you
On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas wrote:
> On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> The fact that the file was "modified" twice after being removed at rev
>>> 2.88 seems really wacko. Are you sure that's not contributing to what
>>> we're seeing her
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Aug 25, 2010 at 12:35:53PM -0400, Robert Haas wrote:
> On Wed, Aug 25, 2010 at 12:02 PM, Michael Haggerty
> wrote:
[...]
> > I must say, it is refreshing to have users who actually care about their
> > conversion, as opposed to the usual ra
1 - 100 of 199 matches
Mail list logo
