[Gluster-devel] Reducing the size of the glusterdocs git repository

Tue May 17 10:26:20 UTC 2016

On Tue, May 17, 2016 at 02:42:27PM +0530, Amye Scavarda wrote:
> Hi all,
> 
> So we have a new slideshare.net account, GlusterCommunity (
> http://www.slideshare.net/GlusterCommunity/) that connects with the
> Gluster.org G+ community - and it'll even connect with the YouTube channel!
> 
> I've submitted a PR to the glusterdocs repo that will need some review: it
> removes all of the presentations from the repo and links to slideshare. (
> https://github.com/gluster/glusterdocs/pull/109)

Cool, but note that the size of the repository does not decrease with
that commit. The git repository will still contain all the presentations
in the history/log. But not adding any more presentations is a good step
already :-)

> In no way does this mean that anyone needs to use Slideshare to host PDFs
> of slides, you can use whatever you want. I chose slideshare because there
> was an older Gluster account that had some Gluster.com presentations and it
> links with YouTube.
> 
> Thoughts?

Looks good to me, but maybe you can address this comment in the GitHub
pull request:
  https://github.com/gluster/glusterdocs/pull/109/files#r63498585

Thanks,
Niels

> - amye
> 
> 
> 
> On Thu, May 12, 2016 at 7:49 PM, Niels de Vos <ndevos at redhat.com> wrote:
> 
> > On Thu, May 12, 2016 at 03:55:23PM +0530, Kaushal M wrote:
> > > On Thu, May 12, 2016 at 1:25 PM, Niels de Vos <ndevos at redhat.com> wrote:
> > > > On Thu, May 12, 2016 at 02:56:52AM -0400, Prashanth Pai wrote:
> > > >>
> > > >>
> > > >> > > Right now, even cloning the main docs branch is a huge pain due
> > to the size
> > > >> > > of the repo.
> > > >> > > I think that branching will solve not this problem, and might
> > make the
> > > >> > > problem worse.
> > > >> >
> > > >> > Branching would not increase the size of the repository itself.
> > Only the
> > > >> > size used on RTD will be bigger as the HTML for different branches
> > will
> > > >> > be generated (so contents is there 2x). Cloning the repository is
> > not
> > > >> > affected.
> > > >> >
> > > >> > Deleting files (like the presentations) will also not remove them
> > from
> > > >> > the git repository. It will stay possible to checkout an older
> > version
> > > >> > of the docs from the same repository, all of the history is
> > downloaded
> > > >> > once the repository is cloned.
> > > >> >
> > > >> > In order to reduce the size of the repository, you need to create a
> > new
> > > >> > one, and import the changes without the big files. While importing
> > > >> > changes from an other (the current) repository, it is possible to
> > modify
> > > >> > the changes on the fly and prevent importing the big files. This
> > keeps
> > > >> > the history and the credits for the contributors.
> > > >>
> > > >> This is an alternative solution:
> > > >> https://rtyley.github.io/bfg-repo-cleaner/
> > > >
> > > > Right, I was thinking about git-filter-branch. In the end, I am pretty
> > > > sure that the old/original repository is not valid anymore. I expect
> > > > that 'git rebase' is used for the cleaning, and that will change the
> > > > commit-ids of patches that follow after a 'cleaned' patch.
> > > >
> > > > Mu recommendation for a seperate repository, is only for preventing
> > > > inconsistencies between the upstream repository (after cleaning) and
> > the
> > > > previously cloned/forked repositories that contributors have.
> > > >
> > > >> > Where would you suggest the presentations (and other files?) should
> > get
> > > >> > located?
> > > >>
> > > >> May be an official Gluster community slideshare or speakerdeck
> > account ?
> > > >
> > > > Possibly something like this. But we should have a plan for the
> > existing
> > > > presentations too. And we have to accept that not everyone presenting
> > > > about a Gluster (related) topic will use 'our' SaaS instance.
> > > >
> > > >> Git LFS is also also an option but we don't really need versioning for
> > > >> presentation files. Git LFS will keep large files in a separate
> > location
> > > >> and keep a "pointer" to those in the repo.
> > > >
> > > > I'd prefer something like this. Most of my presentations are written
> > > > while I'm travelling, so a connected service is not really an option
> > for
> > > > me in any case.
> > >
> > > The docs repo should just have links to the presentations.
> > > They could be hosted on slideshare/speakerdeck, google drive or they
> > > could be hosted html5 presentations.
> > > If required we could just host the presentations on download.gluster.org
> > .
> > > I've seen it being used to host resources for tutorials previously
> > > (like disk images),
> > > so hosting the actual presentations shouldn't be too hard.
> >
> > I really do not care where they are hosted. We just can not demand the
> > use of a SaaS for them. We can offer the option of course, but still
> > allow presenters to use the tool of their preference.
> >
> > Niels
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >
> 
> 
> 
> -- 
> Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160517/514a6adb/attachment.sig>