Hi Uwe
Thanks for helping me! I will inspect these results also!
All the best,
Igor Wiese
2015-12-10 16:45 GMT-02:00 Uwe Schindler :
> Hi,
>
> > We used commits recorded in SVN, not Git. Probably we minimized the
> > problem, but we got much less commits. In fact we analyzed
Hi,
> We used commits recorded in SVN, not Git. Probably we minimized the
> problem, but we got much less commits. In fact we analyzed 4 releases
> from SOLr (1.1, 1.2, 1.3 and 1.4 was the last) and 10 releases from
> Lucene.
The same applies to SVN, too. I just posted the GIT links for easier
Hi MG. Thanks for the portuguese :-)
I really enjoyed your example. I don't know much about the Lucene/Solr
architecture of, but I completely agree. Probably, there is a design
problem in this case because the classes seem to be "related". But some of
pairs of files that we tested, we couldn't
Hi,
There is one general problem in the analysis:
Since approx 5 1/2 years, Lucene and Solr are now one project and no longer
separated (see
https://github.com/apache/solr/blob/trunk/trunk_development_moved.txt;
https://github.com/apache/lucene/blob/trunk/trunk_development_moved.txt).
Hi Uwe.
We used commits recorded in SVN, not Git. Probably we minimized the
problem, but we got much less commits. In fact we analyzed 4 releases
from SOLr (1.1, 1.2, 1.3 and 1.4 was the last) and 10 releases from
Lucene.
About the heavy commit. We found in some cases more than one commit to
a
Hi, Lucene and Solr Community.
My name is Igor Wiese, phd Student from Brazil. In my research I am
investigating two important questions: What makes two files change
together? Can we predict when they are going to co-change again?
I've tried to investigate this question on the Lucene and Solr