Re: [Monotone-devel] git fast-export

[Felipe Contreras]

On Tue, Feb 10, 2009 at 6:58 AM, Derek Scherger <address@hidden> wrote:
>
> On Mon, Feb 9, 2009 at 4:40 PM, Felipe Contreras
> <address@hidden> wrote:
>>
>> I'm getting a bit further now, but I'm still having some
>> incompatibilities. I've tried to emulate most of them, but it takes
>> time between each try.
>
> I've checked in a change that improves performance quite a lot, which I'll
> describe in another email.
>>
>>
>> The first issue I stumbled upon is that you do the following:
>>
>>      db.get_revision_certs(*r, author_cert_name, authors);
>>      db.get_revision_certs(*r, branch_cert_name, branches);
>>      db.get_revision_certs(*r, changelog_cert_name, changelogs);
>>      db.get_revision_certs(*r, comment_cert_name, comments);
>>      db.get_revision_certs(*r, date_cert_name, dates);
>>
>> While I get all the certs and handle them in one single go. I think
>> it's more efficient to do a single sql query. This generates a
>
> sqlite handles rapid-fire queries *much* faster than your average oracle or
> postgresql database does. I would be very surprised if issuing these 5
> queries per rev made any measurable difference to performance, but I have
> been wrong before. ;)
>
>> different order when there's multiple committers. For now I'm doing it
>> separately as your code does.
>>
>> The next one is regarding the changelogs. I want to have only one
>> changelog, not concatenate them. So I patched your code. I'm attaching
>> the patch.
>
> I'm curious as to what the exact problem you're having here is. Can you give
> an example of the messages you're getting and what you would like to have?
>
> The export code should not be repeating changelogs that are due to multiple
> people arriving at the same merge or propagate. The intent of the code
> that's there is that if multiple people did have unique things to say it
> will preserve all of their messages which seems better than randomly
> throwing away someone's comments. It should be retaining only one
> automatically generated merge or propagate message though.

It's just that I don't like that behavior. It doesn't matter how smart
is the algorithm, it will always look like two messages instead of
one, which might be ok for some people, but not for other.

In any case, the first error I got was with a revision that had a
change like this [merge 0123...] and another one like [merge
'0123...].

>> Then I tried to update to your latest revision and I'm getting a
>> failure from fast import. I'm attaching the report.
>
> Yes. Git doesn't like authors without a email address wrapped in < and > so
> you need to put these in the --authors-file mappings.

Why not? I thought '<unknown>' was ok.

-- 
Felipe Contreras