Any problem with a 1.8MB blob in the tree? Re: Please try to upgrade an alpha10 when enforcing new rules in samdb

Andrew Bartlett abartlet at
Mon Aug 16 01:57:30 MDT 2010

On Mon, 2010-08-16 at 09:34 +0200, Stefan (metze) Metzmacher wrote:
> Am 15.08.2010 20:38, schrieb Michael Wood:
> > Hi
> > 
> > On 15 August 2010 12:25, Andrew Bartlett <abartlet at> 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.
> >>
> >> Thoughts?
> > 
> > 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, (
> > 
> > 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
> text.

tdbdump would certainly be a reasonable option.  It would reconstruct
the tdb in a much more accurate manner than ldif would (due to modules,
indexes etc). 

> If we're talking about importing binary stuff from a stable release just
> once,
> 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.

OK.  Could you help Matthieu if he has any problem with the scripts to
create and reconstruct from tdbdump files?


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the samba-technical mailing list