George, I'll let Digy respond to the FSDirectory modifications, as IIRC they are his.
However, the TestStressIndexing2 mods are mine. There are fairly extensive comments here: https://issues.apache.org/jira/browse/LUCENENET-143 To make a long story short, the Java test works in spite of itself. I can comment more fully, if necessary, but I'll have to review the changes to be more specific. -Doug On Fri, Dec 19, 2008 at 8:37 PM, George Aroush <geo...@aroush.net> wrote: > Hi Digy, and Doug > > I have done a code review on the patches that were delivered to the trunk, > and I have some questions: > > * DocumentsWriter.cs > - What is ReadToEnd()? I don't see it being used from anywhere, and it > doesn't exists in the Java version of Lucene. Lets remove it please. > > * FSDirectory.cs > - The constructor FSIndexInput() and FSIndexOutput() have a loop which try > to create a Descriptor / BinaryWriter object. This loop has a try / catch > and loops 10 times before it gives up. There is no such logic in the Java > version of Lucene; why was this added to Lucene.Net? Why 10 times but not > 5, 2, 100? This bothers me since it may be hiding a real port issue. If > this loop is a must, due to the way .NET works, a comment is required to > explain the divergence. > > * TestStressIndexing2.cs > - In IndexSerial(), there is a comment that reads "nonono - can't do this > ..." and then the line fields.Sort(fieldNameComparator) is commented out, > why? This is not the case for Java; in Java it's sorted by calling > Collections.sort(fields, fieldNameComparator). > - In VerifyEquals(), some new C# only code is added (for debugging?) It's > best to avoid such extra code to help reduce delta(s) when working on new > port. > > I don't know which patch introduced the above, still I consider them > divergence from the Java code and should be fixed. > > Regards, > > -- George > >
