Re: cvs2git: One possible bug, and two other issues

On Sun, Jan 9, 2011 at 8:37 AM, Michael Haggerty <[email protected]> wrote:
> On 01/03/2011 03:48 PM, Anders Pilegaard wrote:
>> Issue 2 - 'Why'-information in manufactured commits
>> ---------------------------------------------------
>>
>> Sample repository: ex2.tar
>> Creation script  : create_ex2.sh
>> Patch            : patch2.txt
>>
>> When I test-converted our big CVS repository I saw a huge amount of
>> commits 'Manufactured by cvs2svn'.  For some files the manufactured
>> commits outnumbered the real ones 10 to 1, making the history almost
>> impossible to use.  I wanted to know why they showed up, so I had a
>> chance to get rid of them.
>>
>> To that purpose I modified git_output_option.py.  I renamed
>> _is_simple_copy to _why_not_simple_copy, and modified it to return
>> None for "Ok, this is a simple copy" and a string if not.  The string
>> describes why a simple copy wouldn't work.  The callers of
>> _is_simple_copy are modified to pass the returned string into the
>> commit message of the resulting manufactured commit.
>>
>> The text itself could be more readable, but the current state should
>> be enough as proof-of-concept.  If this idea is accepted the
>> readability can always be improved.
>>
>> I think this would be a good general extension of cvs2git.
>
> This is a good idea in principle.  How verbose are the resulting commit
> messages in practice?  Could you send a few "typical" snippets to the
> mailing list?

I have to keep the real repository confidential, so I can't send live
information.  But the commit messages can become quite verbose.  If
eg. a tag is missing on 100 files there will be 100 lines plus a few
extra at the top ...

> I wonder whether this is the sort of information that people will want
> in their permanent repository history.  Do you think that it is the sort
> of information that will be referred back to after the conversion, or is
> it mostly useful for optimizing/debugging/understanding the conversion
> itself and uninteresting thereafter?  If the latter, perhaps it would be
> more appropriate to store the information into a separate log file,
> somehow indexed to the corresponding commits.  Or perhaps to make its
> inclusion in the log messages optional.

Ideally all debugging should take place before the final conversion,
but in practise I think it would take too long in our case - so we'll
probably need the information stored for later usage.  But not
necessarily in the commit comments though.

The advantage of using the comments is of course that the information
is "inline" in the repository - no need for extra files.  But even if
the details are put in another file, I think it makes sense to give
just a little information in the commit comment.  At least I found it
quite frustrating to see a commit message stating that cvs2git
manufactured this commit without any kind of information on "why" ...
:-)

On the other hand I've found that it would be much nicer during
debugging to have the information collected in one place.  Right now I
have to hunt through the repository to find commits that need a closer
look.  For this purpose it would be very nice with one (large) report
file saying something like:

  Manufactured a total of 1423 commits because a label didn't cover all files:
    [list of label names]
    [list of complete info per label - ie. which files were missing]

  Manufactured a total of 319 commits because a label referenced
multiple LODs (or whatever term is better)
    [list of label names]
    [list of complete info per label ...]

  ... etc ...

Or perhaps even an executive summary first with just the number of
different "interesting" events.

> On a technical level, there are a few things that would have to get
> cleaned up in this patch before it is committed:

Definitely!  My plan was to handle those parts if it was decided to
add such information to the code, and when the details got stable.

Best regards,
  Anders Pilegaard

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

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