[Smtk-developers] git-lfs test repository

[Marcus D. Hanwell]

On Tue, Jul 25, 2017 at 3:32 PM, David Thompson <david.thompson at kitware.com>
wrote:

> Hi Marcus,
>
> > That is odd, I was interested, and just tried cloning
> >
> > $ time git clone https://gitlab.kitware.com/ben.boeckel/cmb-lfs-test.git
> > real    0m39.754s
> > $ time git lfs clone https://gitlab.kitware.com/
> ben.boeckel/cmb-lfs-test.git
> > real    0m18.448s
> >
> > This is with git 2.13.3
> > Definitely faster, and easier to follow output, but both pretty fast
> from 21 on a desktop Linux machine.
>
> I am pretty sure it has a lot to do with your proximity to the data. At
> KRS, it took
>

Totally agree, just trying to add some data points. It would be good to
compare with GitHub too as we would both be remote - at best you can
saturate KHQ's 150Mbps connection, but it could be far worse that that too.


>
>   git clone, Ben's test repo      21m32s
>   git lfs clone, Ben's test repo   6m36s
>   git clone, CMB test-data repo    2m28s
>
> This is git 2.11.0 on macos Sierra. I also installed homebrew git (2.13.3)
> and got a similar time for "git lfs clone" (6m49s).
>

If I understand correctly, Ben was saying newer git makes git clone perform
nearly as well as git lfs clone.

>
> We are planning to move ahead with git-lfs but will prune the larger,
> unused input datasets by not adding them to the repo. If we need large data
> (examples or benchmarking) a separate repo is an option.


Sounds good, we will probably use this approach for Tomviz, but likely on
GitHub with their 1GB limit on LFS data size. We haven't gotten to it yet,
so certainly interested in new findings for an already quite large data
repository.

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170725/6ec85825/attachment-0001.html>