Re: test git conversion

On Wed, Oct 5, 2011 at 5:15 PM, Marko Kreen <markokr@gmail.com> wrote:
> On Wed, Oct 5, 2011 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Marko Kreen <markokr@gmail.com> writes:
>>> - There are few manufactured commits on branches (not on HEAD):
>>
>>> $ grep -i cvs2 cvs2svn-tmp/git-dump.dat
>>> This commit was manufactured by cvs2git to create branch 'REL6_4'.
>>> ...
>>
>>> So the question is does the code look sane around those points
>>> and do we need to do something with it.  As cvs2git has seen improvements
>>> since postgres conversion, perhaps they are ok and we can ignore those.
>>> Especially since they are only on older branches.
>>
>> I don't have details in my head anymore, but when we did the server's
>> git conversion, every one of those "manufactured commits" was a real
>> problem, ie, it didn't represent the history in a nice way.  I think the
>> most common cause was adding a file on HEAD and then on a pre-existing
>> branch, and that the unmodified git conversion then misrepresented the
>> state of the file at earlier instants in that branch (ie, it was there
>> when it should not be).  This is a bug/ambiguity in the CVS
>> representation, there is nothing cvs2git can do about it.  We worked
>> around it in the server conversion by editing the RCS files ... don't
>> know whether you guys are feeling sufficiently anal to do likewise.
>
> I actually got interfaces/jdbc parts from Magnus' repository_fixups
> working against jdbc repo.  Attached script gets rid of two REL7_1 tag
> related commits.
>
> But looking at the script it indeed is not about "representing cvs
> history in git"
> but "working around bad history in cvs".  And it does not affect main branch
> history in any way.
>
> So it's dubious whether it's worthwhile to do it, and in any case I'm
> wrong person to do it, as I'm completely unfamiliar with JDBC
> code, both old and new...

Another approach:

https://github.com/markokr/pgjdbc-clean

I just added line:

  ExcludeRegexpStrategyRule(r'REL[678].*|WIN32_DEV|release-6-3'),

to config, so that only REL9* branches and tags are converted:

 * [new branch]      REL9_0_STABLE -> REL9_0_STABLE
 * [new branch]      REL9_1_STABLE -> REL9_1_STABLE
 * [new branch]      master -> master
 * [new tag]         REL9_0_801 -> REL9_0_801
 * [new tag]         REL9_0_802 -> REL9_0_802
 * [new tag]         REL9_1_901 -> REL9_1_901

No manufactured commits.

I really suggest going with that approach, otherwise the
conversion will be huge amount of delicate work.
Or broken old branches.

Sanity checking is also easier this way.

If needed the interested people can fix and convert
older branches later.

--
marko