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.
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 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
Jeff Davis writes:
> On Tue, 2010-09-07 at 13:30 -0700, David Fetter wrote:
>> Offhand, I'm not thinking of past examples of mutating/disappearing
>> GUC that people would want to freeze, nor of a new GUC that would
>> negate or substantially alter such freezing. What have I missed?
> It just se
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 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
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
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
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
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
Greg Stark wrote:
> The industry standard solution that we're missing that we *should* be
> figuring out how to implement is incremental backups.
>
> I've actually been thinking about this recently and I think we could
> do it fairly easily with our existing infrastructure. I was planning
> on doi
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 6:02 AM, Simon Riggs wrote:
> On Mon, 2010-09-06 at 22:32 +0200, Boszormenyi Zoltan wrote:
>> (in commit)
>> write wal record
>> release locks/etc > wait for sync ack
>>
>> In the first case, the contention is obviously increased.
>> With this, we are creating more idle ti
101 - 113 of 113 matches
Mail list logo
