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

On 01/21/2011 01:13 PM, Anders Pilegaard wrote:
> 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
>>> ---------------------------------------------------
> [...]
> 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 ...

It just occurred to me that one possible place for this information
would be a separate revision property.  Since revision properties can be
deleted retroactively, they wouldn't have to permanently take up space
in the repository.  And having them separate would make it easier to
parse them.

But I still suspect that storing them in a separate file would be more
convenient in most cases.  It's easier to work with a text file than
with svn properties.

> 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.

Surely you will do one or more test conversions before the final
conversion, no?  What's the use of having debugging information related
to the final conversion, if it is impossible to improve the conversion
based on that information (because the new SVN repo is in use)?

> 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.

What would you think of the following compromise?

1. Store, in the commit messages, a short description of why the commit
was manufactured without any details (e.g., no list of files).  Provided
the messages are understandable and not too cumbersome, this could even
be the default behavior.

2. Provide an option to store extensive debugging information to another
file, probably with an "executive summary" at the end.

3. The "executive summary" could also be logged to standard output at
the end of the pass at the default "NORMAL" logging level.

Michael

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

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

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