Re: git: uh-oh

On Wed, Aug 25, 2010 at 12:02 PM, Michael Haggerty <mhagger(at)alum(dot)mit(dot)edu> wrote:
>> I think we should try to do something to clean this up,
>> perhaps by doctoring the file on the CVS side.
>
> This is probably caused by cvs2svn's failure to consider file deletions
> when choosing the best revision from which to branch [1].  It would be
> better to branch all of these symbols from the commit *after* the files
> were deleted, which would make them all exact copies of the original
> (rather than requiring a fixup branch).
>
> I don't think that this can be fixed by doctoring the CVS repository (at
> least, not short of removing the three files from the entire project
> history).  It could be fixed post-conversion by using grafts, or by
> shifting the tags and rebasing the branches.

Well, the history here is pretty weird. In relevant part, here's the
result of cvs log on src/backend/parser/gram.c:

revision 2.92
date: 2007/04/17 01:06:27; author: tgl; state: dead; lines: +0 -0
And remove 'em again ...
----------------------------
revision 2.91
date: 2007/04/17 01:05:07; author: tgl; state: Exp; lines: +0 -12088
Temporarily re-add derived files, in hopes of straightening out their
CVS status.
----------------------------
revision 2.90
date: 1999/05/07 01:22:54; author: vadim; state: Exp; lines: +6001 -5942
branches: 2.90.2;
Fix LMGR for MVCC.
Get rid of Extend lock mode.
----------------------------
revision 2.89
date: 1999/03/28 20:32:04; author: vadim; state: Exp; lines: +3292 -3225
1. Vacuum is updated for MVCC.
2. Much faster btree tuples deletion in the case when first on page
index tuple is deleted (no movement to the left page(s)).
3. Remember blkno of new root page in BTPageOpaque of
left/right siblings when root page is splitted.
----------------------------
revision 2.88
date: 1999/03/20 18:43:49; author: tgl; state: dead; lines: +1 -1
Remove yacc/lex output files from CVS repository.

The fact that the file was "modified" twice after being removed at rev
2.88 seems really wacko. Are you sure that's not contributing to what
we're seeing here?

> I must say, it is refreshing to have users who actually care about their
> conversion, as opposed to the usual rabble who think that git-cvsimport
> is Just Fine :-)  I guess if the postgresql project didn't care about
> data integrity then we would all have to worry :-)

I laughed when I read this - yeah, we're kind of paranoid about that.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company