Re: cvs2git conversion produces "spurious" commits in the history.

On Sun, Oct 7, 2012 at 11:47 PM, Michael Haggerty <[email protected]> wrote:
<snip>
>> As far as I'm aware (and as some quick testing seems to indicate) this
>> will not generate the same RCS file as in my sample repo (or real
>> repo). CVS will not generate an empty commit like that for a file that
>> it knows has not been changed (that is that cvs ci will be a no-op).
>
> If you use the "-f" option, as above, then cvs creates the commit anyway.

You are correct. I missed your use of the -f option when I read this the
other day. That does change things (and not for the better for me).

>>> In this particular case it would be reasonable to merge the two commits
>>> into a single one, moving your "Import from MAIN c" commit message onto
>>> the commit that adds c to b (i.e., sacrificing the autogenerated commit
>>> message, which is anyway misleading).
>>
>> Merging the commits in that direction would generate the wrong history
>> though and CVS knows the timestamp of the correct history (as oppposed
>> to your suggested history above which doesn't contain that additional
>> timestamp information). As far as the actual CVS history is involved
>> in this case the generated commit here seems to be entirely spurious
>> and erroneous.
>
> I don't understand your point.

My point was based on my mistaken understanding and as such was flawed.

I understand more clearly now that the problem is that there isn't a
good way to determine which of the two versions of history actually
occured and is therefore desired in the converted repository. (I could
argue that changesets that involve other files might be more likely to
be later branch additions and not forced branch fixes that's not a
particularly reliable heuristic.)

I'd love to ask at this point for this to be a controllable option but I
know full well that that isn't a particularly reasonable request.

<snip>

>> P.S. Where in cvs2svn is this sort of determination made? What logic
>> is involved exactly? I've been having a difficult time sorting out
>> where all the moving parts in this process are and how they interact.
>
> There is a lot of information in doc/design-notes.txt about the
> algorithms used.
>
> Most of the intelligence for simplifying single-file histories happens
> during FilterSymbolsPass in the class CVSFileItems.
>
> The work of deducing the project-wide commits from all of the
> single-file histories is done in the passes starting with
> InitializeChangesetsPass.

I did read design-notes a bit but that was largely before I had a good
feeling for what was going on. I shall do so again now with special
focus on the passes mentioned.

Thank you.

    -Etan

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

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