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

Reply via email to