It is possible that the many files that are only different in newlines is actually my fault. I think that Jim integrated a load of my changes to the rubyspecs last month but I was having newbie issues with Git and my setup changed a load of the line endings. I have now got over this issue after some mucking about with git config.
I have subsequently had these changes incorporated into the official rubyspec repository on github. If the only files are ones that I broke then you can just bin those commits and use the versions from the official github repository instead. Is there much benefit in keeping a separate fork of mspec and rubyspec now anyway? Ironruby now seems to be able to run mspec unmodified and the guys who manage these projects seem happy to give responsible people commit rights to the official repositories. You could apply tags to versions of rubyspec or mspec to baseline versions that are good for ironruby. In addition there are a number of guards available in mspec that allow rubyspecs to be filtered based on ruby implementation and version. This is how the jruby and rubinius projects use rubyspec. In terms of tracking regression tests for a specific ironruby bug in rubyforge. How about you just list the descriptions of the examples (i.e. "it" blocks) that fail for the bug. It would be fairly easy to check that these now run ok. In many ways the tagged rubyspec examples are a direct representation of the bugs that are still to be solved. Pete -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Srivatsn Narayanan Sent: Monday,29 September 29, 2008 18:07 To: [email protected] Subject: Re: [Ironruby-core] Code Review: rubyspec4 Using the tf diff tool, I see that a lot of files are identical except for changes in newline characters (maybe \n changed to \r\n)? From my random sampling I hardly found any files that have actually changed. Maybe it would help to have a guideline about the preferred newline character. Also, regarding the baselining, how are we planning to track bugs and their related regression tests? If we are closing a bug on rubyforge and want to make sure that regression tests exist for that scenario, it would be good to have a link between the disabled test and the bug itself. In the IronPython testcode this is done by adding a disabled decorator to the test with the bug id. Here maybe a tag can have one more field to indicate the bug id? This is a change to the mspec runner itself and I'm not asking for it to be done with this shelveset but it's something to be discussed about. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bacon Darwin Sent: Monday, September 29, 2008 9:48 AM To: [email protected] Subject: Re: [Ironruby-core] Code Review: rubyspec4 The diff has only 94 bytes -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Deville Sent: Monday,29 September 29, 2008 17:35 To: IronRuby External Code Reviewers; Srivatsn Narayanan Cc: [email protected] Subject: [Ironruby-core] Code Review: rubyspec4 This is a large diff due to updating Rubyspec, MSpec and Ironruby-tags. tfpt review "/shelveset:rubyspec4;REDMOND\jdeville" Comment : Re-syncing MERLIN_EXTERNAL mspec to the head of MSpec to pick up new tests. Re-baselining to get new tests included. _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
