Personally, clone for me is 'rare', I did it once years back, and have never done it since. log, diff and others I do on a daily basis. Same with svn as well actually, you checkout just once usually..
I think the previous discussion had the agreement that this issue should focus on committers rather than contributors. And committers by definition aren't getting started with Solr. If you want to make things more flexible and faster for contributors, sure, github mirror provides an svn facade which allows you to check out a subversion wc from it's repos for read/write (write's not that useful for us though since github is not the primary repo). On 31 May 2015 14:25, "Robert Muir" <rcm...@gmail.com> wrote: > You guys totally miss the point on clone. > > The thing is that svn checkout gives you enough, to do what you need > to do. And yes it does network lookup for more rare things like > history, but this works just fine in general. > > On the other hand git downloads gigabytes, before you can even get started. > > Something needs to be done about all those jars in the source history, > I will not let this go. > > On Sun, May 31, 2015 at 9:16 AM, Ramkumar R. Aiyengar > <andyetitmo...@gmail.com> wrote: > > +1 for git, great for working on multiple things at once. > > > > Side note: git-svn is also not great btw for the kind of merging we need > to > > do with every commit, it kind of works but with too many caveats. > > > > On the note that git clone is slow, sure, because it fetches a fair > amount > > of history which svn doesn't. But to compare just them is unfair, since > > checkout and clone are not identical. If you want to compare times, you > will > > also have to add up every log, diff, or annotate you do on the tree > during > > your development (of which I certainly do a lot and I am sure others do > as > > well), and git will certainly win if you include all those because it > does > > no network lookup. Clone and checkout are typically one time operations, > why > > should their speed be a concern in any case? > > > > I know this has come up a few times in the past but I wanted to bring > this > > up again. > > > > The lucene-solr ASF git mirror has been behind by about a day. I was > > speaking with the infra people and they say that the size of the repo > needs > > more and more ram. Forcing a sync causes a fork-bomb: > > > > Can't fork: Cannot allocate memory at /usr/share/perl5/Git.pm line 1517. > > > > They tried a few things but it's almost certain that it needs even more > RAM, > > which still is a band-aid as they'd soon need even more RAM. Also, adding > > RAM involves downtime for git.a.o which needs to be planned. As a stop > gap > > arrangement attached a volume to the instance and are using it as swap to > > work around the "adding RAM requires restart" issue. > > > > FAQ: How would the memory requirement change if we moved to git instead > of > > mirroring? > > Answer: svn -> git mirroring is a weird process and has quite the memory > > leak. Using git directly is much cleaner. > > > > I personally think git does make things easier to manage when you're > working > > on multiple overlapping things and so we should re-evaluate moving to > it. I > > would have been fine had the mirroring worked, as all I want is a way to > be > > able to work on multiple (local) branches without having to create and > > maintain directories like: lucene-solr-trunk1, lucene-solr-trunk2, or > > SOLR-XXXX, etc. > > > > Opinions? > > > > > > -- > > Anshum Gupta > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
