The lfs cost at GitHub starts at >1Gb. Don’t know how much we have of historic jars in our history. Also, as far as I understand, Apache is free to install their own git-lfs server, so the repository will use an Apache-operated server for storing the large files instead of GitHub’s own storage service. Since we don’t check in jars anymore, this would be a one-time sync to populate lfs, and then git clients will get small pointer files in pace of the large files, and will need to install git-lfs and run "git lfs fetch” in order to replace these with proper binaries.
However, until we know more about why the svn-git mirroring breaks, we cannot say whether LFS would help at all. If we migrate to git (which I’m totally in favor of), I guess LFS could be a way to migrate ALL history at a lower cost, so new users can clone the whole repo faster. It will be the “git lfs fetch” stage that takes time if the user chooses to fetch various large files. For normal usage of current branches it will not be necessary. Win win. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 8. des. 2015 kl. 19.57 skrev Dennis Gove <dpg...@gmail.com>: > > github will reject files larger than 100MB and will warn for files larger > than 50MB (https://help.github.com/articles/working-with-large-files/ > <https://help.github.com/articles/working-with-large-files/>). They have > recently released Git Large File Storage to alleviate issues caused by these > restrictions > (https://github.com/blog/1986-announcing-git-large-file-storage-lfs > <https://github.com/blog/1986-announcing-git-large-file-storage-lfs>) but > there is a cost associated with using such a thing so I would imagine that > path is a no-go. The limit is on a per-file basis and in other projects I've > gotten around it by using split to split large files before adding to a > github repo and then using cat to combine the pieces back before using the > file. I'm not sure how feasible of a solution that would be for us but > perhaps we could add hooks to do the split-ting and cat-ing automatically for > users. > > I'm in favor of a full switch to git (and github). > > Doing would require changes to the ant build scripts as at least one command > (package and related package commands) requires an svn checkout to add some > information to the created package. We'd have to change that logic to instead > look at git metadata. > > On Mon, Dec 7, 2015 at 2:48 AM, Dawid Weiss <dawid.we...@gmail.com > <mailto:dawid.we...@gmail.com>> wrote: > I tried it once (for storing large text files -- Polish dictionaries, > uncompressed -- on github), but it simply didn't work. More headaches > than benefits (to me). > > Dawid > > On Sun, Dec 6, 2015 at 10:04 PM, Doug Turnbull > <dturnb...@opensourceconnections.com > <mailto:dturnb...@opensourceconnections.com>> wrote: > > I had not heard of git-lfs looks promising > > > > https://git-lfs.github.com/?utm_source=github_site&utm_medium=blog&utm_campaign=gitlfs > > > > <https://git-lfs.github.com/?utm_source=github_site&utm_medium=blog&utm_campaign=gitlfs> > > > > > > On Sunday, December 6, 2015, Jan Høydahl <jan....@cominvent.com > > <mailto:jan....@cominvent.com>> wrote: > >> > >> If the size of historic jars is the problem here, would looking into > >> git-lfs for *.jar be one workaround? I might also be totally off here :-) > >> > >> -- > >> Jan Høydahl, search solution architect > >> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > >> > >> 6. des. 2015 kl. 00.46 skrev Scott Blum <dragonsi...@gmail.com > >> <mailto:dragonsi...@gmail.com>>: > >> > >> If lucene was a new project being started today, is there any question > >> about whether it would be managed in svn or git? If not, this might be a > >> good impetus for moving to a better world. > >> > >> On Sat, Dec 5, 2015 at 6:19 PM, Yonik Seeley <ysee...@gmail.com > >> <mailto:ysee...@gmail.com>> wrote: > >>> > >>> On Sat, Dec 5, 2015 at 5:53 PM, david.w.smi...@gmail.com > >>> <mailto:david.w.smi...@gmail.com> > >>> <david.w.smi...@gmail.com <mailto:david.w.smi...@gmail.com>> wrote: > >>> > I understand Gus; but we’d like to separate the question of wether we > >>> > should > >>> > move from svn to git from fixing the git mirror. > >>> > >>> Except moving to git is one path to fixing the issue, so it's not > >>> really separate. > >>> Give the multiple problems that the svn-git bridge seems to have (both > >>> memory leaks + history), perhaps the sooner we switch to git, the > >>> better. > >>> > >>> -Yonik > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> <mailto:dev-unsubscr...@lucene.apache.org> > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> <mailto:dev-h...@lucene.apache.org> > >>> > >> > >> > > > > > > -- > > Doug Turnbull | Search Relevance Consultant | OpenSource Connections, LLC | > > 240.476.9983 <tel:240.476.9983> > > Author: Relevant Search > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > <mailto:dev-unsubscr...@lucene.apache.org> > For additional commands, e-mail: dev-h...@lucene.apache.org > <mailto:dev-h...@lucene.apache.org> > >
