Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: core/store
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      RAMDirectory uses RAMFiles to store the data. RAMFile offers a newBuffer() method for extensions to override and allocate buffers differently, from e.g. a pool or something. However, RAMDirectory always allocates RAMFile and doesn't allow allocating a RAMFile extension, which makes RAMFile.newBuffer() unusable.

      I think we can simply introduce a newRAMFile() method on RAMDirectory and make the RAMFiles map protected, and it will allow really extending RAMDir.

      I will post a patch later.

        Activity

        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1
        Hide
        Robert Muir added a comment -

        I don't think we should allow limitations of our current SCMS to dictate how we develop...

        There was never due to a limitation? Again, whether shai merges from 3x->trunk or trunk->3x was never the problem.
        The problem is in the past someone merging individual files etc (such as Tokenizer.java) and never merged from the top level before committing.

        Show
        Robert Muir added a comment - I don't think we should allow limitations of our current SCMS to dictate how we develop... There was never due to a limitation? Again, whether shai merges from 3x->trunk or trunk->3x was never the problem. The problem is in the past someone merging individual files etc (such as Tokenizer.java) and never merged from the top level before committing.
        Hide
        Michael McCandless added a comment -

        Here's my take: personally i don't see any problem with how Shai works here, as long as its still a proper merge.

        +1

        I don't think we should allow limitations of our current SCMS to dictate how we develop...

        Show
        Michael McCandless added a comment - Here's my take: personally i don't see any problem with how Shai works here, as long as its still a proper merge. +1 I don't think we should allow limitations of our current SCMS to dictate how we develop...
        Hide
        Robert Muir added a comment -

        Here's my take: personally i don't see any problem with how Shai works here, as long
        as its still a proper merge. The mergeprops on things like Tokenizer aren't his fault, its because
        someone merged incorrectly before.

        I just suggest we do the following:

        • always svn update before merging
        • always merge from top-level svn root (if you merged from some other location, then merge again from top level before committing)

        I cleaned up the mergeprops yesterday so the problems Yonik sees shouldn't happen anymore.
        but: its important people do proper merging so that we don't end up in this situation.

        Show
        Robert Muir added a comment - Here's my take: personally i don't see any problem with how Shai works here, as long as its still a proper merge. The mergeprops on things like Tokenizer aren't his fault, its because someone merged incorrectly before. I just suggest we do the following: always svn update before merging always merge from top-level svn root (if you merged from some other location, then merge again from top level before committing) I cleaned up the mergeprops yesterday so the problems Yonik sees shouldn't happen anymore. but: its important people do proper merging so that we don't end up in this situation.
        Hide
        Shai Erera added a comment -

        That's how I worked so far ... I usually develop on 3x and then merge to trunk. I didn't think it will cause troubles . I don't mind developing on trunk and merging to 3x if that will improve anything, but would the history of 3x look like then? Perhaps we should avoid merging on a regular basis and instead apply the patch on both, and then once in a while we do a big mergeprops merge?

        Show
        Shai Erera added a comment - That's how I worked so far ... I usually develop on 3x and then merge to trunk. I didn't think it will cause troubles . I don't mind developing on trunk and merging to 3x if that will improve anything, but would the history of 3x look like then? Perhaps we should avoid merging on a regular basis and instead apply the patch on both, and then once in a while we do a big mergeprops merge?
        Hide
        Simon Willnauer added a comment -

        Looks Good To Me I believe .

        correct!

        Show
        Simon Willnauer added a comment - Looks Good To Me I believe . correct!
        Hide
        Yonik Seeley added a comment -

        Why was this committed to 3x and then merged to trunk?
        Could we try to not merge to trunk and instead merge to 3x? We're destroying the usefulness of our history.
        I thought Tokenizer just changed in trunk... I went to look at the history and the last 17 revisions are all identical (except for mergeprops I assume). And I can't tell at a glance what are real vs fake changes in the history.

        Show
        Yonik Seeley added a comment - Why was this committed to 3x and then merged to trunk? Could we try to not merge to trunk and instead merge to 3x? We're destroying the usefulness of our history. I thought Tokenizer just changed in trunk... I went to look at the history and the last 17 revisions are all identical (except for mergeprops I assume). And I can't tell at a glance what are real vs fake changes in the history.
        Hide
        Shai Erera added a comment -

        Looks Good To Me I believe .

        Show
        Shai Erera added a comment - Looks Good To Me I believe .
        Hide
        Uwe Schindler added a comment -

        Simon: What means LGTM?

        Show
        Uwe Schindler added a comment - Simon: What means LGTM?
        Hide
        Shai Erera added a comment -

        Committed revision 1039151 (3x).
        Committed revision 1039156 (trunk).

        Show
        Shai Erera added a comment - Committed revision 1039151 (3x). Committed revision 1039156 (trunk).
        Hide
        Simon Willnauer added a comment -

        LGTM

        Show
        Simon Willnauer added a comment - LGTM
        Hide
        Shai Erera added a comment -

        Trivial patch. I plan to commit shortly

        Show
        Shai Erera added a comment - Trivial patch. I plan to commit shortly

          People

          • Assignee:
            Shai Erera
            Reporter:
            Shai Erera
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development