[iTowns-dev] Video in repo

[Augustin Trancart]

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 at 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 at 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/itowns-dev/attachments/20170703/248f8e20/attachment-0001.sig>