Robert Haas <[email protected]> writes:
> On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane <[email protected]> wrote:
>> Well, the other side of that argument is that changing these things in
>> the CVS repository will be overwriting the available evidence, in case
>> any questions come up later. On the git side, applying the tag to the
>> appropriate commit is an easy --- and easily changeable --- thing, isn't
>> it?
> You can apply the tag to any commit that you want easily enough, but
> you can't change even the least detail of the commit contents. So if
> it turns out that there's no commit that exactly matches the desired
> tag contents, then things get sticky. That's why we need to make sure
> that the reconstructed series of commits exactly matches what really
> happened as closely as possible the first time through. If it
> doesn't, we're pretty hosed.
I've already found the commits on the CVS side that I think ought to get
the tags --- that's what that "matches" file is about. If cvs2git can't
be trusted to duplicate those tree states then we have bigger problems.
Of course, now that I've got the tarballs I will be rechecking them
against git checkouts as part of the acceptance tests for the final
conversion, but right now I don't foresee a problem here.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
