Proposed Roadmap
All, Following up on Scott's post asking about JIRA issues and our development road map, I've put together a more detailed idea of how we could divide work, schedule releases, and clean up the backlog. There will be at least four main areas of work to address in the upcoming months: - Project Maintenance - Catching up with the backlog - Working on a new porting system - The Future: New API and Lucene 3.X Each one of those paths will need a separate road map and plan. In JIRA these should probably be listed as separate components, along with more structural components like Lucene.Net Core, Lucene.Net Contrib, Luke.Net, etc... Assuming we are working on these in parallel, I've included some rough estimate dates for completion of each listed milestone in the road maps. Project Maintenance == This includes the various aspects of transition from Lucene subproject to Incubator Podling, as well as updating the website and documenation. Roadmap * Website and branding Update (02/28/2011) - LUCENENET-379 - Clean up Lucene.Net website * NOTE: Should probably be split into a few separate issues: * Update website to be Apache CMS based * Update website to reflect current status and information * New site layout * New logo design * Documentation Update (03/28/2011) - LUCENENET-382 - Create a wiki page for Lucene.Net * NOTE: This should probably have more detailed tasks defined and separately assigned / managed. This should focus on 2.9.2 level code, examples, etc, plus FAQ, Design, and other similar documentation. Catching up with the Backlog == This includes finalizing the 2.9.2 release, updating that to Lucene 2.9.4 compatibility and applying outstanding patches and bug fixes. This will put is slightly out of sync with Java Lucene because we'll have additional patches applied that the Java Lucene project does not have for our 2.9.4 release. Roadmap * Lucene.Net 2.9.2 Binary release (02/28/2011) - LUCENENET-381 - Official release of Lucene.Net 2.9.2 * Build from existing tag, no new changes * Lucene.Net 2.9.4 Source/Binary release (03/28/2011) *EASY STUFF* - LUCENENET-389 - Signing the released assembly - LUCENENET-377 - Upgrade solution to VS2010 - LUCENENET-361 - Workaround for a Mono C# compiler issue - LUCENENET-266 - Putting support classes in separate files and in a separate directory - LUCENENET-337 - TokenAttribute for Selectively Including Tokens in Length Norm - LUCENENET-330 - Search.Regex minimal port - LUCENENET-371 - Unit test for Search.Regex port - LUCENENET-374 - IndexReader.IsCurrent returning false positive in some cases - LUCENENET-179 - SnowballFilter speed improvment *HARDER STUFF* - LUCENENET-??? Rollup changes from Lucene 2.9.3/2.9.4 releases - LUCENENET-372 - NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers * NOTE: For v1.4 This code could be a starting point for a 2.9.2 compatible version - LUCENENET-391 - Luke.Net for Lucene.Net * NOTE: For v1.4 This code could be a starting point for a 2.9.2 compatible version - LUCENENET-172 - This patch fixes the unexceptional exceptions ecountered in FastCharStream and SupportClass * NOTE: Evaluate concerns expressed by George A. for this patch - LUCENENET-167 - Compact Framework Silverlight Support * NOTE: Evaluate required steps and impact this will have on source code. Perhaps create a branch for CF/SilverLight. - LUCENENET-378 - Objects with a Close method should support IDisposable * NOTE: Significant diversion from Java, involves a lot of code-touch. Maybe take some ideas from and/or incorporate changes from various CodeProject forks? Working on a New Porting System == We've discussed that we'd like to fully automate this process and so far, the most obvious tool to use is Sharpen. This may involve forking Sharpen (or contributing back to that project if appropriate). We also discussed we'd like a to set up a CI server for this work (and other things). * Evaluate tooling (02/28/2011) - LUCENENET-380 - Evaluate Sharpen as a port tool * NOTE: We should conclusively complete the evaluation and if we're ok with Sharpen, close this issue and move on to building a production version of the Sharpen code. - LUCENENET-??? - Evalute CI systems and build a proposal for CI server setup * Create Production System, 2.9.2 compatible (03/28/2011) - LUCENENET-??? - Create production version of automated port scripts for 2.9.2 build * NOTE: This will allow us to focus on the conversion process, not the Lucene.Net code changes. This will be considered complete when we are able to create a functionally equivalent 2.9.2 port using Sharpen. This can be measured using existing unit tests, or by adding new ones as needed to
RE: Proposed Roadmap
Do you imagine us doing all the catching up on backlog by hand? And then later getting the automated conversion out? From: thowar...@gmail.com Date: Fri, 18 Feb 2011 01:36:00 -0800 Subject: Proposed Roadmap To: lucene-net-dev@lucene.apache.org All, Following up on Scott's post asking about JIRA issues and our development road map, I've put together a more detailed idea of how we could divide work, schedule releases, and clean up the backlog. There will be at least four main areas of work to address in the upcoming months: - Project Maintenance - Catching up with the backlog - Working on a new porting system - The Future: New API and Lucene 3.X Each one of those paths will need a separate road map and plan. In JIRA these should probably be listed as separate components, along with more structural components like Lucene.Net Core, Lucene.Net Contrib, Luke.Net, etc... Assuming we are working on these in parallel, I've included some rough estimate dates for completion of each listed milestone in the road maps. Project Maintenance == This includes the various aspects of transition from Lucene subproject to Incubator Podling, as well as updating the website and documenation. Roadmap * Website and branding Update (02/28/2011) - LUCENENET-379 - Clean up Lucene.Net website * NOTE: Should probably be split into a few separate issues: * Update website to be Apache CMS based * Update website to reflect current status and information * New site layout * New logo design * Documentation Update (03/28/2011) - LUCENENET-382 - Create a wiki page for Lucene.Net * NOTE: This should probably have more detailed tasks defined and separately assigned / managed. This should focus on 2.9.2 level code, examples, etc, plus FAQ, Design, and other similar documentation. Catching up with the Backlog == This includes finalizing the 2.9.2 release, updating that to Lucene 2.9.4 compatibility and applying outstanding patches and bug fixes. This will put is slightly out of sync with Java Lucene because we'll have additional patches applied that the Java Lucene project does not have for our 2.9.4 release. Roadmap * Lucene.Net 2.9.2 Binary release (02/28/2011) - LUCENENET-381 - Official release of Lucene.Net 2.9.2 * Build from existing tag, no new changes * Lucene.Net 2.9.4 Source/Binary release (03/28/2011) *EASY STUFF* - LUCENENET-389 - Signing the released assembly - LUCENENET-377 - Upgrade solution to VS2010 - LUCENENET-361 - Workaround for a Mono C# compiler issue - LUCENENET-266 - Putting support classes in separate files and in a separate directory - LUCENENET-337 - TokenAttribute for Selectively Including Tokens in Length Norm - LUCENENET-330 - Search.Regex minimal port - LUCENENET-371 - Unit test for Search.Regex port - LUCENENET-374 - IndexReader.IsCurrent returning false positive in some cases - LUCENENET-179 - SnowballFilter speed improvment *HARDER STUFF* - LUCENENET-??? Rollup changes from Lucene 2.9.3/2.9.4 releases - LUCENENET-372 - NLS pack for Lucene.NET: BR, CJK, CN, CZ, DE, FR, NL, RU analyzers * NOTE: For v1.4 This code could be a starting point for a 2.9.2 compatible version - LUCENENET-391 - Luke.Net for Lucene.Net * NOTE: For v1.4 This code could be a starting point for a 2.9.2 compatible version - LUCENENET-172 - This patch fixes the unexceptional exceptions ecountered in FastCharStream and SupportClass * NOTE: Evaluate concerns expressed by George A. for this patch - LUCENENET-167 - Compact Framework Silverlight Support * NOTE: Evaluate required steps and impact this will have on source code. Perhaps create a branch for CF/SilverLight. - LUCENENET-378 - Objects with a Close method should support IDisposable * NOTE: Significant diversion from Java, involves a lot of code-touch. Maybe take some ideas from and/or incorporate changes from various CodeProject forks? Working on a New Porting System == We've discussed that we'd like to fully automate this process and so far, the most obvious tool to use is Sharpen. This may involve forking Sharpen (or contributing back to that project if appropriate). We also discussed we'd like a to set up a CI server for this work (and other things). * Evaluate tooling (02/28/2011) - LUCENENET-380 - Evaluate Sharpen as a port tool * NOTE: We should conclusively complete the evaluation and if we're ok with Sharpen, close this issue and move on to building a production version of the Sharpen code. - LUCENENET-??? - Evalute CI systems and build a proposal for CI server setup * Create Production System, 2.9.2 compatible (03/28/2011) - LUCENENET-??? - Create production version of automated port scripts for 2.9.2 build * NOTE: This will allow us to focus on the conversion process, not the Lucene.Net code changes. This will be
Re: Luke.Net
Aaron, Sweet! Hopefully we can repay the favour by making Lucene.Net even more amazing for Umbraco. Was this a port from the Luke code or was this a conceptual re-write? Stephan, Sergey is already planning to include the Apache License header in the files when he imports them. Other than that, is there any legal process we need to go through to bring this code into the Lucene.Net fold? Thanks, Troy On Fri, Feb 18, 2011 at 1:58 AM, Sergey Mirvoda ser...@mirvoda.com wrote: I can take it. On Fri, Feb 18, 2011 at 2:55 PM, Aaron Powell m...@aaron-powell.com wrote: Nope, I've got enough open source projects on my plate that if the Lucene.Net team wants to take over one of them I'm not complaining Aaron Powell Umbraco Core Team Member | FunnelWeb Team Member http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, 18 February 2011 8:51 PM To: lucene-net-dev@lucene.apache.org Cc: Aaron Powell Subject: Re: Luke.Net Aaron, That's awesome! Would you be opposed to us importing this in the Lucene.Net respository, and maintaining it here? Thanks, Troy On Fri, Feb 18, 2011 at 1:47 AM, Aaron Powell m...@aaron-powell.com wrote: A while ago I started working on a port of Luke for .NET, and a colleague of mine also gave a bit of a hand. Neither of us have time to run this project so I'm throwing it open if anyone else wants to work on it you'll find the repo here: http://hg.slace.biz/luke.net/overview Nothing overly exciting, it's a basic WPF app so far, running Lucene.Net 2.9.2, .NET 4.0, VS2010, etc. Aaron Powell Umbraco Core Team Memberhttp://umbraco.codeplex.com/ | FunnelWeb Team Memberhttp://funnelweblog.com/ http://www.aaron-powell.comhttp://www.aaron-powell.com/ | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.commailto:aaz...@hotmail.com -- --Regards, Sergey Mirvoda
Re: Luke.Net
On 2011-02-18, Troy Howard wrote: Sergey is already planning to include the Apache License header in the files when he imports them. Other than that, is there any legal process we need to go through to bring this code into the Lucene.Net fold? Yes, absolutely. First of all you can't change the license without Aaron's consent - and that of all other people who have contributed to Luke.NET so far (I'm assuming it is just Aaron's colleague). I've just performed a cursory look right now and can't find any information about Luke.NET's current license. Second we'd need a software grant by Aaron and his colleague. Alternatively Aaron and his colleague could sign ICLAs but for complete code imports a sofware grant is preferred. See http://www.apache.org/licenses/. If the code was created on company time Aaron may need to check with his employer and have the employer sign a SGA or CCLA, but he'll know better than us. Finally we'd have to follow the IP-Clearance process http://incubator.apache.org/ip-clearance/index.html before the code can be imported. Sorry if this sounds a bit like too much legal hassle, but this is the only way the ASF can be sure it has all necessary rights to actually distribute the code. Stefan
Re: Incubator Infra: JIRA
On 2011-02-18, Digy wrote: Sorry, I am not admin. That's bad. I filed https://issues.apache.org/jira/browse/INFRA-3462 Stefan
RE: Luke.Net
Yeah I'm actually quite lax about remembering to put license on my code. I've just thrown up the MIT license on it. I'll speak to my colleague, but I know I didn't work on it during work time Aaron Powell Umbraco Core Team Member | FunnelWeb Team Member http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Friday, 18 February 2011 10:50 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Luke.Net On 2011-02-18, Troy Howard wrote: Sergey is already planning to include the Apache License header in the files when he imports them. Other than that, is there any legal process we need to go through to bring this code into the Lucene.Net fold? Yes, absolutely. First of all you can't change the license without Aaron's consent - and that of all other people who have contributed to Luke.NET so far (I'm assuming it is just Aaron's colleague). I've just performed a cursory look right now and can't find any information about Luke.NET's current license. Second we'd need a software grant by Aaron and his colleague. Alternatively Aaron and his colleague could sign ICLAs but for complete code imports a sofware grant is preferred. See http://www.apache.org/licenses/. If the code was created on company time Aaron may need to check with his employer and have the employer sign a SGA or CCLA, but he'll know better than us. Finally we'd have to follow the IP-Clearance process http://incubator.apache.org/ip-clearance/index.html before the code can be imported. Sorry if this sounds a bit like too much legal hassle, but this is the only way the ASF can be sure it has all necessary rights to actually distribute the code. Stefan
Re: Site
Ayende, I opened a JIRA issue for this here: https://issues.apache.org/jira/browse/INFRA-3463 Thanks, Troy On Wed, Feb 16, 2011 at 1:23 PM, Ayende Rahien aye...@ayende.com wrote: Off topic, can we get a [Lucene.NET] prefix for messages to the list? On Wed, Feb 16, 2011 at 11:05 PM, Prescott Nasser geobmx...@hotmail.comwrote: Where does that site compile to? The incubator lucene.net site appears to be the older one
Re: Luke.Net
Alternatively we can reimplement it from scratch. Using Aarron's code as a working prototype. Also looks like my most wished (and somewhat advanced) features (testing Analizers and Luke plugins) is not implemented. On Fri, Feb 18, 2011 at 5:01 PM, Aaron Powell m...@aaron-powell.com wrote: Yeah I'm actually quite lax about remembering to put license on my code. I've just thrown up the MIT license on it. I'll speak to my colleague, but I know I didn't work on it during work time Aaron Powell Umbraco Core Team Member | FunnelWeb Team Member http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Friday, 18 February 2011 10:50 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Luke.Net On 2011-02-18, Troy Howard wrote: Sergey is already planning to include the Apache License header in the files when he imports them. Other than that, is there any legal process we need to go through to bring this code into the Lucene.Net fold? Yes, absolutely. First of all you can't change the license without Aaron's consent - and that of all other people who have contributed to Luke.NET so far (I'm assuming it is just Aaron's colleague). I've just performed a cursory look right now and can't find any information about Luke.NET's current license. Second we'd need a software grant by Aaron and his colleague. Alternatively Aaron and his colleague could sign ICLAs but for complete code imports a sofware grant is preferred. See http://www.apache.org/licenses/. If the code was created on company time Aaron may need to check with his employer and have the employer sign a SGA or CCLA, but he'll know better than us. Finally we'd have to follow the IP-Clearance process http://incubator.apache.org/ip-clearance/index.html before the code can be imported. Sorry if this sounds a bit like too much legal hassle, but this is the only way the ASF can be sure it has all necessary rights to actually distribute the code. Stefan -- --Regards, Sergey Mirvoda
RE: Incubator Infra: JIRA
Hi Sergey, I added you too. DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 6:55 PM To: lucene-net-dev@lucene.apache.org Subject: Re: Incubator Infra: JIRA Hi, DIGY My jira user name is sergey_mirvoda. https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sergey_mirvoda Sergey On Fri, Feb 18, 2011 at 9:47 PM, Digy digyd...@gmail.com wrote: After I got the admin rights, I added all commiters as administrators(except Sergey, since I couldn't find his JIRA username). DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, February 18, 2011 8:20 AM To: lucene-net-dev@lucene.apache.org Cc: Stefan Bodewig Subject: Re: Incubator Infra: JIRA I'm not terribly familiar with JIRA. Is it possibile that we can have more than one person as administrator? I'd like to be able to work on the Roadmap, and start doing some scheduling, but currently don't have enough permissions to make those kinds of changes. DIGY - As admin can you grant admin access to others? Thanks, Troy On Thu, Feb 10, 2011 at 1:50 AM, Stefan Bodewig bode...@apache.org wrote: Hi, the LUCENENET JIRA is now listed as project in incubation and Digy is the new administrator. No other changes, so I think this piece of infrastructure is done. Stefan -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
+1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda
Re: Luke.Net
Pending resolution of the legal issues around ingesting the code into Lucene.Net, I've created a public fork of Luke.Net on bitbucket as a staging area to prepare the code for ingestion. Sergey will be working on it there. Thanks, Troy On Fri, Feb 18, 2011 at 6:23 AM, Stefan Bodewig bode...@apache.org wrote: On 2011-02-18, Aaron Powell wrote: Yeah I'm actually quite lax about remembering to put license on my code. I've just thrown up the MIT license on it. Thanks. I'll speak to my colleague, but I know I didn't work on it during work time Depending on your legislation (and your contract) your employer may even own code you write on your own. Cheers Stefan
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
But I would prefer do the same thing on my own local copy and create a patch for trunk. Thanks, DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, February 18, 2011 11:39 PM To: lucene-net-dev@lucene.apache.org Cc: Sergey Mirvoda Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
For folks who badly need to compile it, why not just add a batch file to build the project. It is one line: %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj /t:Clean;Rebuild /p:Configuration=Release On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard thowar...@gmail.com wrote: It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Why with 2.0 and not with 4.0 targeting 2.0? On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett wyatt.barn...@gmail.comwrote: For folks who badly need to compile it, why not just add a batch file to build the project. It is one line: %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj /t:Clean;Rebuild /p:Configuration=Release On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard thowar...@gmail.com wrote: It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Although why wait until after the official release? Just for Lucene.Net users who doesn't use VS2010 and want to use the latest version. DIGY -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Friday, February 18, 2011 11:27 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
That works, only if you're working alone, and don't mind not committing your changes until your work is complete. Many developers don't feel comfortable with that work flow. It's one of the main reasons Mercurial/Git/etc is so popular now. You can commit locally, then push to a central repo later. Thanks, Troy On Fri, Feb 18, 2011 at 1:52 PM, Digy digyd...@gmail.com wrote: But I would prefer do the same thing on my own local copy and create a patch for trunk. Thanks, DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Friday, February 18, 2011 11:39 PM To: lucene-net-dev@lucene.apache.org Cc: Sergey Mirvoda Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda
RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Why not having a release targeting 2.0, 3.5 and 4.0, then updating the project to 4.0 DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 11:56 PM To: lucene-net-dev@lucene.apache.org Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Why with 2.0 and not with 4.0 targeting 2.0? On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett wyatt.barn...@gmail.comwrote: For folks who badly need to compile it, why not just add a batch file to build the project. It is one line: %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj /t:Clean;Rebuild /p:Configuration=Release On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard thowar...@gmail.com wrote: It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
4.0 rules them all. You can release 2.0 3.5 and 4.0 versions with 4.0 multitargeting On Sat, Feb 19, 2011 at 2:59 AM, Digy digyd...@gmail.com wrote: Why not having a release targeting 2.0, 3.5 and 4.0, then updating the project to 4.0 DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 11:56 PM To: lucene-net-dev@lucene.apache.org Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Why with 2.0 and not with 4.0 targeting 2.0? On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett wyatt.barn...@gmail.comwrote: For folks who badly need to compile it, why not just add a batch file to build the project. It is one line: %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj /t:Clean;Rebuild /p:Configuration=Release On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard thowar...@gmail.com wrote: It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Good point. Main reason I used that is I could copy it out of the batch file I was using which was meant to be friendly to the VS2005/2.0 project . .. On Fri, Feb 18, 2011 at 5:02 PM, Sergey Mirvoda ser...@mirvoda.com wrote: 4.0 rules them all. You can release 2.0 3.5 and 4.0 versions with 4.0 multitargeting On Sat, Feb 19, 2011 at 2:59 AM, Digy digyd...@gmail.com wrote: Why not having a release targeting 2.0, 3.5 and 4.0, then updating the project to 4.0 DIGY -Original Message- From: Sergey Mirvoda [mailto:ser...@mirvoda.com] Sent: Friday, February 18, 2011 11:56 PM To: lucene-net-dev@lucene.apache.org Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Why with 2.0 and not with 4.0 targeting 2.0? On Sat, Feb 19, 2011 at 2:54 AM, Wyatt Barnett wyatt.barn...@gmail.comwrote: For folks who badly need to compile it, why not just add a batch file to build the project. It is one line: %windir%\Microsoft.NET\Framework\v2.0.50727\msbuild lucene.net.csproj /t:Clean;Rebuild /p:Configuration=Release On Fri, Feb 18, 2011 at 4:38 PM, Troy Howard thowar...@gmail.com wrote: It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda ser...@mirvoda.com wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott slomb...@kingindustries.com wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc. -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda -- --Regards, Sergey Mirvoda
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
Disclaimer: Troy's Personal Opinions (tm) which may be controversial, will be found below Regarding the idea of 'feature branches', I guess I should make it clear that I personally don't agree with this workflow in SVN. This is completely appropriate for Mercurial or Git, because they were designed for that. SVN however, was not, and branching becomes costly because it bloats the repo, causing updates or initial downloads to be much larger, and merging is confusing and difficult with SVN. Also, a big part of this is that many people have the opinion that 'trunk' should be stable. I think this philosophy is incorrect. Instead, stable revisions should be tagged, and trunk should be viewed as unstable, possibly not building or functioning correctly. Commits should occur frequently, and be isolated to a very small scope per commit. When an end user wants to get a stable build, then they can look to the tags directory to find the version they want, and work from that. Branches should be reserved for changes that are made to those tagged revisions. I also think that each project should have it's own repository, instead of bundling many into a single repo. This allows for better version tracking. SVN external can be used to bring complex composites of projects together into a single resulting application. This part of SVN is often overlooked as well, and we lump everything into one huge repository. I wish we had Mercurial here at Apache, because I honestly feel it's a MUCH better system because it allows these kinds of workflows. SVN doesn't really do that well. So, unpleasant as it may be, the strategy I described above works best within the SVN system. When in Rome... Thanks, Troy On Fri, Feb 18, 2011 at 3:04 PM, Prescott Nasser geobmx...@hotmail.com wrote: Perhaps that's Prescott's intention with the new vs2010 branch? Yes that's the intention. I started to look at what Wyatt did https://issues.apache.org/jira/browse/LUCENENET-377. I think feel that it works well as designed. Question: Wyatt has included the nunit.dll's I know we had a conversation before about this. But I think being able to pull down everything, open a single solution which has test, contrib, src, as well as the required dependancies would be a huge boon to getting people to work on this stuff. Every change I need to make for 2.9.2-2.9.5 requires me to touch the tests. it just makes sense from my perspective to have this all in the same solution ready to roll. Is this something people are open too having in the source control, or something I should keep to my local? Also, I don't recall the legal stuff behind including nunit. Obviously a release would just be the src rolled up and packaged. From: thowar...@gmail.com Date: Fri, 18 Feb 2011 13:38:47 -0800 Subject: Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ To: lucene-net-dev@lucene.apache.org CC: ser...@mirvoda.com It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev Log: (empty) Added: incubator/lucene.net/branches/vs2010/ - copied from r1069573, incubator/lucene.net/trunk/ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential,
Re: svn commit: r1072121 - /incubator/lucene.net/branches/vs2010/
using svn externals makes it harder on people who would use tools like git-svn for version control on their local box. On Fri, Feb 18, 2011 at 7:46 PM, Troy Howard thowar...@gmail.com wrote: Disclaimer: Troy's Personal Opinions (tm) which may be controversial, will be found below Regarding the idea of 'feature branches', I guess I should make it clear that I personally don't agree with this workflow in SVN. This is completely appropriate for Mercurial or Git, because they were designed for that. SVN however, was not, and branching becomes costly because it bloats the repo, causing updates or initial downloads to be much larger, and merging is confusing and difficult with SVN. Also, a big part of this is that many people have the opinion that 'trunk' should be stable. I think this philosophy is incorrect. Instead, stable revisions should be tagged, and trunk should be viewed as unstable, possibly not building or functioning correctly. Commits should occur frequently, and be isolated to a very small scope per commit. When an end user wants to get a stable build, then they can look to the tags directory to find the version they want, and work from that. Branches should be reserved for changes that are made to those tagged revisions. I also think that each project should have it's own repository, instead of bundling many into a single repo. This allows for better version tracking. SVN external can be used to bring complex composites of projects together into a single resulting application. This part of SVN is often overlooked as well, and we lump everything into one huge repository. I wish we had Mercurial here at Apache, because I honestly feel it's a MUCH better system because it allows these kinds of workflows. SVN doesn't really do that well. So, unpleasant as it may be, the strategy I described above works best within the SVN system. When in Rome... Thanks, Troy On Fri, Feb 18, 2011 at 3:04 PM, Prescott Nasser geobmx...@hotmail.com wrote: Perhaps that's Prescott's intention with the new vs2010 branch? Yes that's the intention. I started to look at what Wyatt did https://issues.apache.org/jira/browse/LUCENENET-377. I think feel that it works well as designed. Question: Wyatt has included the nunit.dll's I know we had a conversation before about this. But I think being able to pull down everything, open a single solution which has test, contrib, src, as well as the required dependancies would be a huge boon to getting people to work on this stuff. Every change I need to make for 2.9.2-2.9.5 requires me to touch the tests. it just makes sense from my perspective to have this all in the same solution ready to roll. Is this something people are open too having in the source control, or something I should keep to my local? Also, I don't recall the legal stuff behind including nunit. Obviously a release would just be the src rolled up and packaged. From: thowar...@gmail.com Date: Fri, 18 Feb 2011 13:38:47 -0800 Subject: Re: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ To: lucene-net-dev@lucene.apache.org CC: ser...@mirvoda.com It's a common practice for developers to create a branch to work on a new feature, then merge that branch back into trunk later when the changes are complete, then delete the branch. The goal is to ensure that incremental commits, performed now against the branch instead of trunk, don't leave trunk in a incompatible, unstable or un-buildable state. Perhaps that's Prescott's intention with the new vs2010 branch? Thanks, Troy On Fri, Feb 18, 2011 at 1:31 PM, Sergey Mirvoda wrote: +1 for only one trunk upgraded to VS2010 On Sat, Feb 19, 2011 at 2:27 AM, Lombard, Scott wrote: I agree with DIGY. Although why wait until after the official release? Scott -Original Message- From: Digy [mailto:digyd...@gmail.com] Sent: Friday, February 18, 2011 3:38 PM To: lucene-net-dev@lucene.apache.org Subject: RE: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Do we really need a VS2010 branch?. Since there isn't any release since v2.0 and people have to compile the source by yourselves it has been good to support older versions of VS. But after having an offical release, we could update the trunk to support VS2010. Now for each change in trunk (for v2.9.3, 2.9.4 2.9.5) we have to update another repository also. DIGY -Original Message- From: pnas...@apache.org [mailto:pnas...@apache.org] Sent: Friday, February 18, 2011 10:11 PM To: lucene-net-comm...@lucene.apache.org Subject: svn commit: r1072121 - /incubator/ lucene.net/branches/vs2010/ Author: pnasser Date: Fri Feb 18 20:10:54 2011 New Revision: 1072121 URL: http://svn.apache.org/viewvc?rev=1072121view=rev
[jira] Updated: (LUCENENET-379) Clean up Lucene.Net website
[ https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-379: Component/s: Project Infrastructure Due Date: 28/Feb/11 (was: 31/Dec/10) Assignee: Troy Howard Labels: Website (was: ) Remaining Estimate: 336h Original Estimate: 336h Clean up Lucene.Net website --- Key: LUCENENET-379 URL: https://issues.apache.org/jira/browse/LUCENENET-379 Project: Lucene.Net Issue Type: Task Components: Project Infrastructure Reporter: George Aroush Assignee: Troy Howard Labels: Website Attachments: Lucene.zip, New Logo Idea.jpg, asfcms.zip, asfcms_1.patch Original Estimate: 336h Remaining Estimate: 336h The existing Lucene.Net home page at http://lucene.apache.org/lucene.net/ is still based on the incubation, out of date design. This JIRA task is to bring it up to date with other ASF project's web page. The existing website is here: https://svn.apache.org/repos/asf/lucene/lucene.net/site/ See http://www.apache.org/dev/project-site.html to get started. It would be best to start by cloning an existing ASF project's website and adopting it for Lucene.Net. Some examples, https://svn.apache.org/repos/asf/lucene/pylucene/site/ and https://svn.apache.org/repos/asf/lucene/java/site/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LUCENENET-379) Clean up Lucene.Net website
[ https://issues.apache.org/jira/browse/LUCENENET-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-379: Remaining Estimate: 80h (was: 336h) Original Estimate: 80h (was: 336h) Clean up Lucene.Net website --- Key: LUCENENET-379 URL: https://issues.apache.org/jira/browse/LUCENENET-379 Project: Lucene.Net Issue Type: Task Components: Project Infrastructure Reporter: George Aroush Assignee: Troy Howard Labels: Website Attachments: Lucene.zip, New Logo Idea.jpg, asfcms.zip, asfcms_1.patch Original Estimate: 80h Remaining Estimate: 80h The existing Lucene.Net home page at http://lucene.apache.org/lucene.net/ is still based on the incubation, out of date design. This JIRA task is to bring it up to date with other ASF project's web page. The existing website is here: https://svn.apache.org/repos/asf/lucene/lucene.net/site/ See http://www.apache.org/dev/project-site.html to get started. It would be best to start by cloning an existing ASF project's website and adopting it for Lucene.Net. Some examples, https://svn.apache.org/repos/asf/lucene/pylucene/site/ and https://svn.apache.org/repos/asf/lucene/java/site/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LUCENENET-377) Upgrade solution to VS2010
[ https://issues.apache.org/jira/browse/LUCENENET-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-377: Component/s: Lucene.Net Core Affects Version/s: .NET API Lucene.Net 3.x Lucene.Net 2.9.4 Lucene.Net 2.9.2 Fix Version/s: Lucene.Net 2.9.2 Assignee: Prescott Nasser Labels: solution (was: ) Remaining Estimate: 10m Original Estimate: 10m Upgrade solution to VS2010 -- Key: LUCENENET-377 URL: https://issues.apache.org/jira/browse/LUCENENET-377 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 3.x, .NET API Reporter: Jeffrey Cameron Assignee: Prescott Nasser Labels: solution Fix For: Lucene.Net 2.9.2 Attachments: lucene.zip Original Estimate: 10m Remaining Estimate: 10m VS2005 is quite out of date now and there are many new improvements in VS2010. You can still leave the framework support at .NET 2.0 if you like. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (LUCENENET-393) Lucene - Search Engine for .net Issue
[ https://issues.apache.org/jira/browse/LUCENENET-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard closed LUCENENET-393. --- Resolution: Cannot Reproduce Assignee: Scott Lombard This is more of a question than Issue. If more detailed information on the problem is presented this issue can be reopened Lucene - Search Engine for .net Issue - Key: LUCENENET-393 URL: https://issues.apache.org/jira/browse/LUCENENET-393 Project: Lucene.Net Issue Type: Bug Environment: Win server 2003 SP2,.net 3.5 with sp1,AMD processor 2 GHz 4GB RAM Reporter: Rahul Panwar Assignee: Scott Lombard Priority: Blocker We have implemented the Lucene.net for site search. We have implemented this in following steps: 1.Processing index from Database (around 4 million records are in DB) to file system. 2.Implement search on indexed file. It's working fine for us and results are very fast in development environment but when we have published this to production server is getting slow and process w3wp.exe taking 40-50% CPU continuously. We have implemented this for two applications and in this case 100% CPU utilized by w3wp.exe. Please suggest if there is any workaround for this issue? OR also let us know if it's a known issue in Lucene? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Bug Fixes for Lucene.Net versions before 2.9.2
What is the group's feeling on bug fixes on problems found in versions before 2.9.2? Scott This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
RE: Bug Fixes for Lucene.Net versions before 2.9.2
Unless they affect current release, I think we need to let them be. Once we get to 2.9.5 we should probably continue to support that with bug fixes for quite a while, but at some point that too should fall off our list. ~Prescott From: slomb...@kingindustries.com To: lucene-net-dev@lucene.apache.org Date: Sat, 19 Feb 2011 00:41:33 -0500 Subject: Bug Fixes for Lucene.Net versions before 2.9.2 What is the group's feeling on bug fixes on problems found in versions before 2.9.2? Scott This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
[jira] Updated: (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-391: Component/s: Lucene.Net Contrib Description: .net port of Luke.Net for Lucene.Net (was: .net port of Luke.Net for Lucene.Net 1.4) Affects Version/s: Lucene.Net 2.9.2 Labels: Luke.Net (was: ) Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Affects Versions: Lucene.Net 2.9.2 Reporter: Pasha Bizhan Priority: Minor Labels: Luke.Net Attachments: luke-net-bin.zip, luke-net-src.zip .net port of Luke.Net for Lucene.Net -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996708#comment-12996708 ] Scott Lombard commented on LUCENENET-391: - Public fork of Luke.Net on bitbucket as a staging area to prepare the code for ingestion. Waiting on Licensing issues to be resolved. Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Affects Versions: Lucene.Net 2.9.2 Reporter: Pasha Bizhan Priority: Minor Labels: Luke.Net Attachments: luke-net-bin.zip, luke-net-src.zip .net port of Luke.Net for Lucene.Net -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (LUCENENET-398) Prepare the code for ingestion
Prepare the code for ingestion -- Key: LUCENENET-398 URL: https://issues.apache.org/jira/browse/LUCENENET-398 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Contrib Reporter: Scott Lombard Prepare source to be imported in the Lucene.Net respository -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LUCENENET-398) Prepare the code for ingestion
[ https://issues.apache.org/jira/browse/LUCENENET-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-398: Assignee: Sergey Mirvoda Prepare the code for ingestion -- Key: LUCENENET-398 URL: https://issues.apache.org/jira/browse/LUCENENET-398 Project: Lucene.Net Issue Type: Sub-task Components: Lucene.Net Contrib Reporter: Scott Lombard Assignee: Sergey Mirvoda Prepare source to be imported in the Lucene.Net respository -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (LUCENENET-389) Signing the released assembly
[ https://issues.apache.org/jira/browse/LUCENENET-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Lombard updated LUCENENET-389: Component/s: Lucene.Net Core Due Date: 28/Feb/11 Priority: Critical (was: Major) Affects Version/s: Lucene.Net 2.9.2 Fix Version/s: Lucene.Net 2.9.2 Issue Type: Improvement (was: Wish) Remaining Estimate: 16h Original Estimate: 16h Signing the released assembly - Key: LUCENENET-389 URL: https://issues.apache.org/jira/browse/LUCENENET-389 Project: Lucene.Net Issue Type: Improvement Components: Lucene.Net Core Affects Versions: Lucene.Net 2.9.2 Reporter: Patric Forsgard Priority: Critical Fix For: Lucene.Net 2.9.2 Original Estimate: 16h Remaining Estimate: 16h In the project I working in i need a signed version of the Lucene.Net-assembly. For the moment I will compile and sign with my own key but it would be great if the official release already should be signed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Index AutoCAD files
Hi team, Is there a way lucene.Net can index AutoCAD files – “*.dwg” files? If so, please let me know. Can you please provide some insight on the same? Thanks in advance.. Regards Vignesh
