Have we heard anything more from Infrastructure? It seems the thing to do right now is to get more of a conversation going with them to understand the issue at hand. Once the release is done, I'd be happy to try and get that conversation going faster than it is.
Upayavira On Tue, Dec 8, 2015, at 06:57 PM, Dennis Gove wrote: > github will reject files larger than 100MB and will warn for files > larger than 50MB > (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) > 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> 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> 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 >> > >> > >> > On Sunday, December 6, 2015, Jan Høydahl > <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 >> >> >> >> 6. des. 2015 kl. 00.46 skrev Scott Blum <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> wrote: >> >>> >> >>> On Sat, Dec 5, 2015 at 5:53 PM, david.w.smi...@gmail.com >> >>> <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 >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >> >> >> > >> > >> > -- >> > Doug Turnbull | Search Relevance Consultant | OpenSource > Connections, LLC | >> > 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 >> For additional commands, e-mail: dev-h...@lucene.apache.org >>
