Don't assume your workflow is everyone else's workflow. And don't try to enforce your workflow on me.
I don't use svn OR git in the way you describe. On Sun, May 31, 2015 at 9:31 AM, Ramkumar R. Aiyengar <andyetitmo...@gmail.com> wrote: > 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org