You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2011/01/12 07:06:07 UTC

[Solr Wiki] Update of "CommitterInfo" by SteveRowe

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "CommitterInfo" page has been changed by SteveRowe.
The comment on this change is: Moved SVN merging info to a dedicated page on the Lucene wiki.
http://wiki.apache.org/solr/CommitterInfo?action=diff&rev1=13&rev2=14

--------------------------------------------------

  
  == SVN Merging ==
  
+ See [[http://wiki.apache.org/lucene-java/SvnMerge|Subversion Merge]] on the Lucene wiki.
- During the time period just before a release, when a release branch has already been made and bug fixes are found that are (nearly) identical on both the trunk and in the release branch, the "[[http://svnbook.red-bean.com/en/1.0/re16.html|svn merge]]" command is usually the most straight forward way to merge changes made onto the trunk to a branch.
- 
- Unlike a more simplistic approach of committing the same patch to both the trunk and the branch, using svn merge helps preserve file history information (like renaming files, or adding new files).
- 
- For example.  If you have branch-1.3 checked out as your current working directory, and you want to merge the exact changes committed to the trunk in r690343 to the branch, you can use...
- {{{
- svn merge -c 690343 https://svn.apache.org/repos/asf/lucene/dev/trunk
- }}}
- 
- See also...
- 
-  * [[http://svnbook.red-bean.com/en/1.0/ch04s03.html|Copying Changes Between Branches]]
-  * [[http://svnbook.red-bean.com/en/1.0/ch04s04.html|Common Use-Cases for Merging]]
- 
  
  == Generating New Analysis Factories ==
  
  Anytime the Lucene jars are updated, we should attempt to generate Factories for any new Tokenizer or !TokenFilter classes.  To do this, run `ant stub-factories -Dstub.src.path="./src:../lucene/contrib:../lucene/src/java"` Where the "stub.src.path" property is set to be a "path like list" of java source directories that should be crawled when looking for classes to make factories for.
  
- This task will first use reflection on all of the `dist` jars to find known subclasses of Tokenizer or !TokenFilter which do not already have Factories and write this list to `build/need-stub-factories.txt`.  It will then crawl the directories specified in `stub.src.path` looking for the corresponding source files to determine what the constructor parameter names are (this info is not available in the byte code) for each class, and generate a new factory for it.  
+ This task will first use reflection on all of the `dist` jars to find known subclasses of Tokenizer or !TokenFilter which do not already have Factories and write this list to `build/need-stub-factories.txt`.  It will then crawl the directories specified in `stub.src.path` looking for the corresponding source files to determine what the constructor parameter names are (this info is not available in the byte code) for each class, and generate a new factory for it.
  
  Classes with no special constructor parameters will get full fledged factories.  Classes with special params will get abstract "stub" factories that will not compile without human editing.