On Thu, May 12, 2016 at 1:25 PM, Niels de Vos <ndevos@xxxxxxxxxx> 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. > > Thanks, > Niels > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
