On Wed, 4 Apr 2007, Dana How wrote:

quoted text
> The motivations are to better support portable media,
> older filesystems,  and larger repositories without
> awkward enormous packfiles.

I wouldn't qualify "enormous" pack files as "awkward".

It will always be more efficient to have only one pack to deal with 
(when possible of course).

quoted text
> When --pack-limit[=N] is specified and --stdout is not,
> all bytes in the resulting packfile(s) appear at offsets
> less than N (which defaults to 1<<31).  The default
> guarantees mmap(2) on 32b systems never sees signed off_t's.
> The object stream may be broken into multiple packfiles
> as a result,  each properly and conventionally built.
> 

This sounds fine.  *However* how do you ensure that the second pack (or 
subsequent packs) is self contained with regards to delta base objects 
when it is _not_ meant to be a thin pack?

quoted text
> When --stdout is also specified,  all objects in the
> resulting packfile(s) _start_ at offsets less than N.
> All the packfiles appear concatenated on stdout,
> and each has its object count set to 0.  The behavior
> without --stdout cannot be duplicated here since
> lseek(2) is not generally possible on stdout.

Please scrap that.  There is simply no point making --pack-limit and 
--stdout work together.  If the amount of data to send over the GIT 
protocol exceeds 4G (or whatever) it is the receiving end's business to 
split it up _if_ it wants/has to.  The alternative is just too ugly.

quoted text
> When --blob-limit=N is specified,  blobs whose uncompressed
> size is greater than or equal to N are omitted from the pack(s).
> If --pack-limit is specified, --blob-limit is not, and
> --stdout is not,  then --blob-limit defaults to 1/4
> of the --pack-limit.

Is this really useful?

If you have a pack size limit and a blob cannot make it even in a pack 
of its 
own then you're screwed anyway.  It is much better to simply fail the 
operation than leaving some blobs behind.  IOW I don't see the 
usefulness of this feature.


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