Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

From Markus Wanner
Subject Re: PostgreSQL Developer meeting minutes up
Date
Msg-id 20090604101118.21274vvayif3y5ye@mail.bluegap.ch
Whole thread Raw
In response to Re: PostgreSQL Developer meeting minutes up  (Greg Stark <stark@enterprisedb.com>)
Responses Re: PostgreSQL Developer meeting minutes up  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
Hi,

Quoting "Greg Stark" <stark@enterprisedb.com>:
> This is all completely irrelevant to the CVS import.

To the CVS import it is, yes. After all, CVS has no notion of renaming
files. But my example is about renaming with git *after* the
conversion. Git *does* support renaming (to some extent). However, it
fails as explained if you feed it with "corrupt" data (the corruption
being the missing link between the two added files - after a rename,
git simply has no chance of knowing it should be the same file).

> I don't think
> we've ever renamed files because CVS can't handle it cleanly.

Yes, that applies to the past. But I think we *are* going to rename
files *after* the switch, because git *can* handle it cleanly - given
a correct import.

If that defect would only affect historic information, I'd not be half
as pestering as I am. But it's such delayed effects which might
surprise you years after the cause, which make me nervous.

> It does sound to me like we really ought to have merge commits marking
> the bug fixes in old releases as merged in the equivalent commits to
> later branches based on Tom's commit messages.

Now, I don't know how you got to that conclusion, but I absolutely agree ;-)

Regards

Markus Wanner



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Synchronous replication: status of standby side
Next
From: Greg Stark
Date:
Subject: Re: PostgreSQL Developer meeting minutes up