Re: git: uh-oh

Magnus Hagander <magnus@hagander.net> 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 should just
> be a replay of the exact same steps we used for the final testing
> repository, which is hard to guarantee if we need to set this up
> manually each time.

Absolutely.  What I had in mind is that we have a predetermined patch
to apply to the repository, and take care that we don't touch that
particular file or files in CVS between making/testing the patch and the
final migration.

At the moment I'm thinking there are probably not going to be that many
files affected.  The technique I showed last night only seems to work if
there is a dead revision on HEAD at the time the branch should sprout;
which was the case for it.po, but it likely applies in only one or two
other places.  The more common case is that the file never existed at
all before the time of the branch divergence.  Possibly Max's technique
will work better for those cases, but I've not had time to try it yet.

Right at the moment, though, we have bigger problems.  There's no point
in expecting cvs2git to produce sane output from insane input, and I've
now found at least three places where the tags in the CVS repository
are flat out not sane.  (The third is that the recently-added regression
test files in contrib/xml2/ have REL8_0_23 tags.  Which is not sane
because they did not exist when that branch was tagged.)  So I think the
first order of business is to try to validate the CVS tags against the
archived tarballs, and see what else turns up.
        regards, tom lane