[iTowns-dev] Video in repo

[Thomas Broyer]

If itowns.github.io contains manually-maintained files, then if we want
good documentation we will care about clone performance.

But yes, that's what I meant (only one commit in gh-pages)

Le 3 juil. 2017 7:41 PM, "Augustin Trancart" <augustin.trancart at oslandia.com>
a écrit :

You mean to never have more than one commit in gh-pages? It is a solution
too, yes.

We thought about pushing all our docs directly to itowns.github.io,
removing the
need of gh-pages branch. We don't really care if this repo is slow to clone
(as
few people will ever do it), and we'll keep the doc history that way. WDYT?

Augustin Trancart - Oslandia
augustin.trancart at oslandia.com

On 03/07/2017 19:35, Thomas Broyer wrote:
> Instead of removing gh-pages altogether (unless there's a good reason to
do so),
> couldn't we change the auto-deploy script to force-push?
>
> Otherwise sounds good (the old files I recalled of were in
> resources/ https://github.com/iTowns/itowns2/commit/
95bf265e33923c0a8e45b06558160e76f414e00d)
>
> Le 3 juil. 2017 7:13 PM, "Augustin Trancart" <augustin.trancart at oslandia.
com
> <mailto:augustin.trancart at oslandia.com>> a écrit :
>
>     To be more precise: a prerequisite for this is to manage to upload
our docs to
>     itowns.github.io <http://itowns.github.io>. Pepp and I are currently
working
>     on this.
>
>     Augustin Trancart - Oslandia
>     augustin.trancart at oslandia.com <mailto:augustin.trancart at oslandia.com>
>
>     On 03/07/2017 19:06, Augustin Trancart wrote:
>     > Ok so, I intent to drastically reduce the size of the repo by
removing
>     from its
>     > history the branches:
>     > - gh-pages (only when deploy to itowns.github.io <
http://itowns.github.io>
>     will work)
>     > - gh-master
>     >
>     > and the files:
>     > - dist/* (will be partly done by removal of gh-pages)
>     > - build/*
>     > - data/*
>     > - resources/*
>     > - doc/*
>     > - src/Core/Commander/Providers/Potree/workers.js (and actually
maybe Potree/
>     > directly)
>     > - src/ThirdParty
>     > - examples/gpx/ULTRA2009.gpx
>     > - API_Doc/ (should be done by removal of gh-pages)
>     >
>     > This implies a force-push on *all* the branches. Therefore, it is
advised that
>     > you *clone the repo back once it's done*. You'll probably need to
resubmit
>     your
>     > PR. I can help for the rebase if necessary.
>     >
>     > I'll keep a copy of the repo just in case :-)
>     >
>     > Schedule: TOMORROW!
>     >
>     > If you see something wrong in this, please raise your hand !
>     >
>     > Augustin Trancart - Oslandia
>     > augustin.trancart at oslandia.com <mailto:augustin.trancart@
oslandia.com>
>     >
>     > PS: FYI, when aggressively testing locally, I reduce the repo size
from
>     103Mb to
>     > 3.9MB.
>     >
>     > On 29/06/2017 15:56, Augustin Trancart wrote:
>     >> Ok, so I continued my investigation, and apart from this video,
the size
>     of the
>     >> repo is also big because of the dist folder we commit to gh-pages
at each
>     >> merge... I'm pretty sure that does count more than the video
itself (which
>     >> shouldn't take more than it's compressed raw size, as it has not
been changed
>     >> since its appearance). And I don't really know how to workaround
that.
>     >>
>     >> So I'm not sure it is worthy to rewrite the entire history for
gaining
>     just 20mb
>     >> (max) of our 110mb repo any more. Maybe we should just live with
it, as
>     only the
>     >> first clone is slow.
>     >>
>     >> Suggestions?
>     >>
>     >> Augustin Trancart - Oslandia
>     >> augustin.trancart at oslandia.com <mailto:augustin.trancart@
oslandia.com>
>     >>
>     >> On 29/06/2017 14:26, Thomas Broyer wrote:
>     >>>
>     >>>
>     >>> 2017-06-29 13:51 GMT+02:00 Augustin Trancart
>     <augustin.trancart at oslandia.com <mailto:augustin.trancart at oslandia.com
>
>     >>> <mailto:augustin.trancart at oslandia.com
>     <mailto:augustin.trancart at oslandia.com>>>:
>     >>>
>     >>>     I basically trust maintainer not to merge big files,
>     >>>
>     >>>
>     >>> Oh, you mean like for that video file? :troll:
>     >>>
>     >>>
>     >>>     but yes, if we can automate it, it's even better.
>     >>>
>     >>>
>     >>> Note that apparently aabc913 didn't went through a pull request,
so we
>     couldn't
>     >>> have prevented it anyway (Travis could have failed, and then a
>     push-force would
>     >>> have been needed anyway)
>     >>>
>     >>> Cordialement,
>     >>> --
>     >>> Thomas Broyer
>     >>> Atol Conseils et Développements
>     >>>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> iTowns-dev mailing list
>     >> iTowns-dev at lists.osgeo.org <mailto:iTowns-dev at lists.osgeo.org>
>     >> https://lists.osgeo.org/mailman/listinfo/itowns-dev
>     <https://lists.osgeo.org/mailman/listinfo/itowns-dev>
>     >>
>     >
>     >
>     >
>     > _______________________________________________
>     > iTowns-dev mailing list
>     > iTowns-dev at lists.osgeo.org <mailto:iTowns-dev at lists.osgeo.org>
>     > https://lists.osgeo.org/mailman/listinfo/itowns-dev
>     <https://lists.osgeo.org/mailman/listinfo/itowns-dev>
>     >
>
>
>     _______________________________________________
>     iTowns-dev mailing list
>     iTowns-dev at lists.osgeo.org <mailto:iTowns-dev at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/itowns-dev
>     <https://lists.osgeo.org/mailman/listinfo/itowns-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/itowns-dev/attachments/20170703/6e8915bf/attachment.html>