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

On Fri, Jan 21, 2011 at 3:52 PM, Michael Haggerty <[email protected]> wrote:
> 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.

I think I agree with going for a separate file.  For conversion
debugging it makes most sense to have everything in one place -
getting an overview and finding things to look at will be easier.  And
for later reference it is always possible to check in this file in the
resulting repository.

>> 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)?

I'm already doing such conversions now ... :-) ... Its just that this
repository is quite large, so I don't think I'll be able to look at
everything before the final conversion.  So I want as much information
as possible available later on if we encounter something strange.  It
will be more work at that point, but at least we'll have a better
chance of repairing it later on.

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

I think it sounds good.  And I think it would be very good to have a
little 'why'-information present as default.  It won't make the
comments much larger, but it will provide the reader with the first
clues for understanding that particular commit - and make the path
towards debugging/tweaking the conversion somewhat easier.

/Anders

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

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