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]

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 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.
> >>
> >> 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, (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
> 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?

Thanks, 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
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: <http://lists.samba.org/pipermail/samba-technical/attachments/20100816/93267e56/attachment.pgp>