Re: Further debugging of iterative imports

On 12/15/2010 10:56 AM, Alex Bennee wrote:
> On 14 December 2010 20:33, Michael Haggerty <[email protected]> wrote:
>> On 12/14/2010 08:12 PM, Alex Bennee wrote:
>>> The right hand side is the second import and as you can see from the
>>> log two files that were in their own commit have this time been
>>> wrapped up into another commit.
>>>
>>> Looking at the CVS log entry for that redundancy.c I can see the
>>> following: [...]
>>>
>>> The log for coswd/coswdtrap/coswdtrap.c is totally different: [...]
>>
>> That fact that the log messages are different is irrelevant, because
>> what cvs2svn is combining into one commit are not the r1.1 versions of
>> each file, but the act of adding the two files to branch
>> 'vectastar-3-3-20-red-e1-opt-branch'.  CVS does not record any metadata
>> when a file is added to a branch, so cvs2svn tries to group them
>> together whenever there is not another constraint that prevents it from
>> doing so.
> 
> It seems a little odd as the manufactured commit is using date/time
> straight out of the log. It seems the lumping together should be
> constrained by the commit times.

Since git requires a commit date, cvs2git manufactures a commit date for
the manufactured commit.  It does this by looking at the *real* revision
commits near the branching point and picking a timestamp between them
(in fact, I think it uses the latest timestamp of the commits that
necessarily precede the branching point.

>>> Can anyone offer a pointer to where cvs2svn makes the decision on
>>> creating these manufactured commits and how it decides which ones
>>> match?
>>
>> See doc/design-notes.txt and doc/symbol-notes.txt in the source tree.
>> Either there is some source of indeterminacy in the heuristics that are
>> being used to select changesets (which might be fixable with minimal
>> work), or you are experiencing a case where later changes to the CVS
>> repository are causing the heuristics to make different choices during
>> the second conversion compared to the first one (only fixable with
>> massive work).
> 
> It's certainly not the second case as these files haven't been touched
> in a while. I shall have a poke around and see if I can figure out
> where it's going wrong.

There can be non-local effects related to some cycle somewhere in the
dependency graph.  For all the gory details you can start cvs2git in
-vvvvvvv ery verbose mode and see what the intermediate passes are doing
to split dependency loops (though for a large repository the output is
enormous).  But some other indeterminacy cannot be ruled out without
more information.

We should think about how we can create small test cases for "these two
conversions produce inconsistent overlapping histories".  For example,
if one had a copy of the "before" and "after" CVS repository, one could
incrementally remove the differences between them and see when the
inconsistency goes away.  Then one could run some kind of
"shrink_test_case.py" in parallel on the two repositories, keeping the
inconsistency as an invariant.  The result might be two repositories
that are converted inconsistently but small enough to analyze by hand.

Michael

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2690864

To unsubscribe from this discussion, e-mail: [[email protected]].