Thanks, all. This is the best of answers.. "The
functionality you want is already available if you
just know where to look".
Of course my life would be easier if my employer
used either JIRA or IntelliJ, but perhaps Eclipse
will show me something similar
er...@nevermind.com
On Mon, Mar 8, 20
On 03/08/2010 at 4:37 PM, Robert Muir wrote:
> > Also, in the open source realm:
> >
> > 3. ViewVC (formerly ViewCVS) has a facility to query revision
> history, including commit messages. Apache's instance, which serves
> Lucene's repository, doesn't expose this functionality, though
> >
>
I use "svn diff --change " to get the list of files associated
with a given commit.
You might also want to look at http://freshmeat.net/projects/svnweb/
HTH
-h
From: Erick Erickson
To: java-user
Sent: Mon, March 8, 2010 2:48:41 PM
Subject: Searching Subversi
I am not trying to evangelise git, but more just curious if you guys have ever
looked at switching to a distributed source control system. The branching /
merging capabilities mean you really don't have to use patches to collect
changes from non trusted parties.
See this google tech talk if you
> Also, in the open source realm:
>
> 3. ViewVC (formerly ViewCVS) has a facility to query revision history,
> including commit messages. Apache's instance, which serves Lucene's
> repository, doesn't expose this functionality, though
>
I think it does? Do you mean this functionality?
http:
Hi Erick,
On 03/08/2010 at 3:48 PM, Erick Erickson wrote:
> Is there any convenient way to, say, find all the files associated with
> patch ? I realize one can (hopefully) get this information from
> JIRA, but... This is a subset of the problem of searching Subversion
> comments.
I know of tw
Ahm you can open the JIRA issue and click on Subversion commits...
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Erick Erickson [mailto:erickerick...@gmail.com]
> Sent: Monday, March 08, 2010 10:30 PM
>
Hi Otis!
Your examples look JIRA-centric, not code-centric. Frankly I'm not
sure there's a difference for my use-case, but
Let's say I want to answer the question "what source files were
changed for JIRA-1234". Currently I'd have to open up the JIRA and
collate all the changed files by openin
Hi Erick,
For what it's worth, we are considering indexing JIRA comments over on
http://search-lucene.com/ , though I'm not entirely convinced searching in
comments would be super valuable. Would it?
But note that JIRA (and LucidFind) already do that. For example, go to
http://issues.apache.
Before I reinvent the wheel.
Is there any convenient way to, say, find all the files associated with
patch ? I realize one can (hopefully) get this information from JIRA,
but... This is a subset of the problem of searching Subversion comments.
I can see it being useful, especially for peo
You don't have to close, immediately. Ie you can use more than one at
once. And in fact in a typical app, where in-flight queries may be
using the old reader, you can't close that old reader until all the
queries are done.
But you must eventually close them else you'll leak descriptors.
Mike
O
So I learned that IndexReader objects must be closed immediately following a
reopen. But what is the guidance after using IndexWriter.getReader()? Does
one reader need closed before getting and using another, or can one use 2 or
more readers simultaneously? I don't see any guidance at the fol
On Mon, Mar 8, 2010 at 1:18 PM, Christopher Laux wrote:
> I'm not sure if this is the right list, as it's sort of a development
> question too, but I don't want to bother them over there. Anyway, I'm
> curious as to the reason for using "manual memory management" a la
> ByteBlockPool and consorts
Hi all,
I'm not sure if this is the right list, as it's sort of a development
question too, but I don't want to bother them over there. Anyway, I'm
curious as to the reason for using "manual memory management" a la
ByteBlockPool and consorts in Java. Is it for performance reasons
alone, to avoid t
Thanks, Mike -- that makes sense. Yes, the fields would be known in advance
so the codec would know to ignore them at index time.
Thanks,
Chris
Lucene doesn't optimize for this today.
But with flex (still on branch but hopefully landing on trunk soon)
you could impl a codec that did optimize such fields. You would know,
in advance, which field(s) do this, right?
And at searching time the codec would pretend all docs appeared in the
post
16 matches
Mail list logo
