Thanks for the brain dump. I have started the gears rolling over on this side of the fence. It may be a bit as this is a corporate timescale I am working with - I am on board though.
Even though you may not hear from me for a week or so do not think for a moment that I am not on top of my commitment - I am the architect and my focus is not always that of a laser but I do get the job done. When I am ready to pull the trigger, I don't want to be the build master but rather a progenitor of the system - meaning I will pave the way, but all the other developers need to march on it. So, with that said, when the systems goes live, I will have (barring any concerns in choices) two servers (1 Linux, 1 Windows) that you can point to. These servers will: * Watch the SVN server for any changes to the build configuration * Update itself with any new build configuration scripts * Watch the SVN server for any referenced projects * Build any changed projects * Run any unit tests * Create distributions My Technology choices that I can see are: * CCnet * Nant * NUnit * NCover * NDoc (or better) * Anything else that runs on Linux and Windows The general idea is to be able to make a build configuration that will execute the same on windows as well as Linux (mono) - I have never done it so I might be speaking the impossible but I would at least like to try. I expect that I cannot as I doubt MSBuild is available in Mono. These machines will either be at my office on our huge pipes or at my house on a decent cable modem - either way, it will be done. Thanks for all the hard work thus far! Christian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Pryor Sent: Sunday, October 18, 2009 7:30 AM To: [email protected] Subject: [dblinq] Re: Error compiling r1237 in VS2008 from fresh SVN On Sat, 2009-10-17 at 23:10 -0700, Christian Jensen wrote: > The first question I have is - am I in the right place? Yes, this is the right place. > There is mention of this being integrated into Mono - should I be there? Mono has a copy of DbLinq to implement System.Data.Linq.dll. DbLinq (this project) is the "upstream" (main) project. > If I am in the right place then I need to make a comment - I am unable > to get the project to build. Erickson Qua committed a fix for this (as I'm sure you've seen). I committed a more appropriate fix in r1239. > There is a reference to an object type that is not of the correct > visibility. In namespace DbLinq.Firebird the class FirebirdSqlProvider > in the method GetTranslator() the "New" is trying to create a type of > "FirebirdExpressionTranslator" which cannot be seen as it has not > visibility declaration. Actually, the problem was that FirebirdExpressionTranslator.cs wasn't in the System.Data.Linq project, and thus the type didn't exist. > I have a cruise control server I can drop this project onto and allow > public access - this might help out with this sort of error. I'm sure that would be appreciated. > I would love to investigate this project further and even contribute > but need some guidance - how much help do you need if any and how can > I help. We need lots of help. :-) In addition to a continuous integration server (which you've gracefully offered), we also need developers to "take care of" databases. For example, we have hundreds of tests. Not all tests pass under all databases. (In fact, not all tests pass for any database, period.) Some (read: me) find this very difficult to fix a given test case when there's no way to easily know if any other tests were broken, as the test suites are never "green." The solution we've chosen so far is to annotate known-failures with NUnit's [Explicit] attribute for *release* builds. This allows us to take the Release unit test build and have the known-failures automatically skipped, so release test runs can actually be green. We do this with some #if logic, e.g.: #if !DEBUG && (MSSQL && !L2SQL) [Explicit] #endif This test says that for release builds (!DEBUG) and DbLinq's Microsoft SQL Server support (MSSQL && !L2SQL -- L2SQL is defined when building tests against Microsoft's Linq-to-SQL provider), the test should be skipped. Meanwhile, SQLite executes this test without error. The problem is that the known-failures vary for each DB, and we don't want to skip all known-failures across all DB's (as with the above test, we don't want SQLite to regress), so this is effectively a tax on developers. Furthermore, not all developers have access to all databases. For example, I only have access to SQLite and SQL Server Express. Consequently I have no way of knowing which tests are known failures under PostgreSQL, Firebird, Oracle, etc. So as part of a continuous integration server, you would need to do two things: 1. Decide which databases you want to test. At minimum this should include SQLite (as it runs everywhere). 2. For the databases chosen from (1), make sure that there aren't any failing tests. You can find database configuration instructions at: http://groups.google.com/group/dblinq/web/unit-tests Thanks, - Jon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
