Re: test git conversion

Maciek Sakrejda <msakrejda@truviso.com> writes:
> Kris had pointed out something like this, too. I had looked at the
> most recent few manufactured commits and didn't see any problems
> (i.e., they were empty and could simply have been filtered out), but I
> investigated further and you're absolutely right: starting shortly
> before the 8.2-508 tag (and all the way back to the beginning), there
> are some bogus commits leading to a weird history: e.g.,
> https://github.com/davecramer/pgjdbc/commit/266a282e221a33e6e5f52f5388ea739528267f70
> . It's hard to see this without a visualizer like gitk, but that
> commit has two parents, merging the master branch into what it claims
> is the newly-created 8.2 branch (which in fact has been around for a
> while by that point, as evidenced by all the 8.2.x tags). This sort of
> thing seems to happen over and over. I can't quite follow what it's
> doing (or the mailing list explanations I've found, for that matter),
> possibly since I have extremely limited experience with CVS (and I
> thank my lucky stars for that). I also tried with a newer cvs2git, but
> no dice.

Many of the problems in the core conversion stemmed from the weird way
in which CVS deals with files that are added to branches later than they
are added to mainline.  Originally, CVS had no way to represent the fact
that such a file had not existed on the branch all the way back to the
time of its addition to mainline; although any tags you'd added to the
branch in between would not be on such a file, making it apparent that
it wasn't really there.  So cvs2git sees an inconsistent history and has
to do something ugly to fix it.

Later on, the CVS people invented a kluge way to represent this situation,
so it's possible that you don't have any such cases in recent history.
Basically the kluge requires inserting a deletion event on the branch at
the time of the file's creation on master.  We did that by hand-editing
the RCS files when we did the core conversion, which was a tad more
exciting than I would've liked, but there weren't really enough cases
to justify building a tool for it.

There were also assorted problems stemming from having done squirrelly
things back in the day, like moving the point from which the REL7_1
branch had been sprouted.  I'm not clear on how much of that might
affect the JDBC repository.

There's lots and lots of detail in the pgsql-hackers archives about
this, around mid September 2010.

            regards, tom lane