> When we did the core conversion, all the "manufactured" commits turned
> out to be due to problems in the CVS repository, and we fixed them by
> tweaking the repository contents before running the conversion. There's
> lots of detail in the pgsql-hackers archives.
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.
I think if we care about history, moving forward with the migration
without resolving this would be a mistake. I'll pore over the core
list history on this and see what I can see. Advice from anyone with
CVS background welcome--e.g., are there any (Linux, ideally, but
Windows works) tools for visualizing CVS history (like gitk for git?).
Does TortoiseCVS support that (I vaguely recall that TortoiseSVN
does)?
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com