Or perhaps someone needs to optimize that repo? (-gc or something?)
It's so damn slow to pick up a couple updates, there is no way it
could have been this slow before without me noticing I think. It's
ridiculous - it may have been slow previously, but I don't think this
slow.
This happens over ti
On 11/12/2012 02:49 AM, Uwe Schindler wrote:
One more thing: If we intend to start testing patches from JIRA with Jenkins
(as Grant proposed, the JIRA plugin for this was implemented by some Hadoop
people, as far as I remember), we need the SVN metadata to cleanly apply
patches in heavy-commit
On Mon, Nov 12, 2012 at 2:04 AM, David Smiley (@MITRE.org)
wrote:
> Simon,
> Your response confuses me.
>
> "3. pull into trunk only from upstream"
>
> Do you mean a local branch "trunk", and coming from apache?
yeah
>
> "... and push to github"
>
> What; you can push to github's mirror? I thoug
Hi,
> > apply using the standard unix "patch -p1" (to get rid of the crazy a/b path
> prefix, also not existent in the SVN diffs). After that I must take care to
> not
> forget to add files, adjust svn props because only stock "svn patch" command
> can do this for me.
>
> Don't want to go into f
> apply using the standard unix "patch -p1" (to get rid of the crazy a/b path
> prefix, also not existent in the SVN diffs). After that I must take care to
> not forget to add files, adjust svn props because only stock "svn patch"
> command can do this for me.
Don't want to go into flame wars,
Hi,
> Any way... seeing you guys use git as committers is encouraging as I thought
> the git side simply is too 2nd class citizen for Lucene/Solr to be effective
> for
> committers. Guess not. I'll have to do what Simon's doing. Woohoo!
> Hopefully it's okay to post git patches to JIRA instead
On Nov 11, 2012, at 4:08 PM, Dawid Weiss wrote:
> It's always been kind of slow for me,
Okay - perhaps I just didn't notice before - but that would be odd. I never
worried much about it's speed, but I also have not used it in a while. This is
the first time I said "jesus, this is slow". But w
Simon,
Your response confuses me.
"3. pull into trunk only from upstream"
Do you mean a local branch "trunk", and coming from apache?
"... and push to github"
What; you can push to github's mirror? I thought it was read-only?
And do you mind telling me/us how you take a change you commit to t
> It was not slow before, so I'd rather the issue be addressed rather than
> ignore it.
It's always been kind of slow for me, with the symptoms you mentioned --
counting objects going forever, etc. I'm using git-svn, but it has
nothing to do with it, a git pull would sometimes fetch a lot. I thin
On Nov 11, 2012, at 3:27 PM, Radim Kolar wrote:
>
>> It did not used to be this way for me, and I'm not seeing this on any other
>> git projects I work with. Anyone else notice this?
> yes, its very slow. use github
>
It was not slow before, so I'd rather the issue be addressed rather than
It did not used to be this way for me, and I'm not seeing this on any other
git projects I work with. Anyone else notice this?
yes, its very slow. use github
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For a
Hey mark,
my workflow is as follows:
1. cloned lucene/solr on github
2. added apache mirror as upstream remote
3. pull into trunk only from upstream
4. branch for each feature and push to github
I never modify trunk or pull from github and my updates are usually
pretty fast ~ 1-5 sec.
yet, I do
12 matches
Mail list logo
