Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> 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