Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 6, 2013 at 3:58 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>>> The story is different on the fast-import side, where we do say we
>>> dump the full table and a later run can depend on these marks.
>>
>> Yes, and gaining nothing but increased disk-space.
>
> I thought that the "gaining nothing" has already been refuted by the
> discussion several hours ago...
>
> cf. http://thread.gmane.org/gmane.comp.version-control.git/223275/focus=223440
>
> Puzzled...

What is being gained there? Nothing.

>>> By discarding marks on blobs, we may be robbing some optimization
>>> possibilities, and by discarding marks on tags, we may be robbing
>>> some features, from users of fast-export; we might want to add an
>>> option "--use-object-marks={blob,commit,tag}" or something to both
>>> fast-export and fast-import, so that the former can optionally write
>>> marks for non-commits out, and the latter can omit non commit marks
>>> if the user do not need them. But that is a separate issue.
>>
>> How?
>
>  * if we teach fast-import to optionally not write marks for blobs
>    and trees out, your remote-bzr can take advantage of it,

I already said remote-bzr is irrelevant. *Everybody* benefits.

>    Existing users like cvs2git that do not ask to skip marks for
>    non-commits will not be hurt and keep referring to blobs an
>    earlier run wrote out.

cvs2git does *not* store marks. It doesn't get any benefit or get hurt *at all*.

>  * if we teach fast-export to optionally write marks for blobs and
>    trees out, the users of fast-export could reuse marks for blobs
>    and trees in later runs (perhaps they can drive fast-export from
>    the output of "git log --raw", noticing blob object names they
>    already saw).  Existing users that do not ask for such a feature
>    will not be hurt.

There's absolutely no benefit from fast-export being able to load and
store blobs, the only effect is that the mark files will have tons of
entries nobody will ever use.

If you want to add options for features that only hurt, go ahead, but
the only sane default is to only store commit marks, both for
fast-export, and fast-import. Period.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]