Any problem with a 1.8MB blob in the tree? Re: Please try to upgrade an alpha10 when enforcing new rules in samdb
Stefan (metze) Metzmacher
metze at samba.org
Mon Aug 16 01:34:24 MDT 2010
Am 15.08.2010 20:38, schrieb Michael Wood:
> On 15 August 2010 12:25, Andrew Bartlett <abartlet at samba.org> wrote:
>> Is there any problem adding a 1.8MB blob to our samba4 testsuite? It is
>> an old Samba4 provision we wish to upgrade. We may add more in future,
>> and it could get out of hand, but on the flip side, without this we
>> can't hold to our promises about upgrades very well.
> I don't think it's really recommended to put large binary blobs in the
> repository. (Whether you consider 2MB to be large is a separate issue
> :) It's not really a problem with Subversion because if you check out
> a revision without the large file you don't pay for it. With git, you
> will always get every revision of every large binary file when you
> clone (unless you do a shallow clone, but then I don't think you can
> push changes from the cloned repository to anywhere else.)
> "Pro Git" says this, (http://progit.org/book/ch9-7.html):
> There are a lot of great things about Git, but one feature that can
> cause issues is the fact that a git clone downloads the entire
> history of the project, including every version of every file. This is
> fine if the whole thing is source code, because Git is highly
> optimized to compress that data efficiently. However, if someone at
> any point in the history of your project added a single huge file,
> every clone for all time will be forced to download that large file,
> even if it was removed from the project in the very next commit.
> Because it’s reachable from the history, it will always be there.
> Also, a cursory search on google shows many people trying to remove a
> large file from the history of their repository, which seems to imply
> that getting the large file into the repo in the first place should
> probably be avoided.
I'd really like to avoid putting large binary files into the git repo.
I'd preferr to have them as text files (ldif or tdbdump) this way we can
update them to newer versions and git has a chance to compress most of the
If we're talking about importing binary stuff from a stable release just
for upgrade tests between major releases it might be acceptable to put them
in (if we really can't find a text based solution), but for upgrades between
alpha releases I think it's bad.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical