migration of subversion to parrot.org

[chromatic]

On Saturday 17 January 2009 10:08:29 Mark Glines wrote:

> As I understand it, the svn properties
> used by parrot just tell svn to rewrite things like $Id$ (which git-svn
> doesn't bother to do), and to use native line endings for text files
> (which git-svn also might not bother to do).  Hmm.  It's possible to
> work easily without the former, but development on various platforms
> might get bitten by the latter.  (I haven't tested it, but it sounds
> problematic.)

It's not.  It's really, really not.  I've asked multiple times for anyone to 
tell me for which files it's problematic.

Once upon a time in the annals of history, a couple of IO tests failed because 
they assumed certain line-ending characters which aren't the same across 
operating system families.  At that time a degree came down from on high 
saying "We shall make sure that all files in the repository always have native 
line endings set via Subversion properties."

Then someone had the idea to test that with a test, which ran every time you 
typed 'make test', adding about 30% of total time to all test runs, at least 
when I measured it, to make sure we never failed the two tests we'd failed 
once and fixed to be more cross-platform.

I agree that big chunks of whitespace changes in diffs are annoying.  I have 
no problem with enforcing properties to work around deficiencies in our tools 
that we can't readily correct.

As far as I can tell -- and again, no one's been able to show me otherwise in 
years of asking -- the desire to keep these tests around is just voodoo, based 
on one experience.

(Meanwhile, if I may extend this rant slightly, we've collectively spent many 
more times the time and effort detecting and correcting failing non-functional 
tests, such as "Oh no, a missing Svn ID line!" and "You left a trailing space 
on a line!", not that the latter is consistently enforced throughout *many* 
directories in Parrot.  Search for trailing spaces in examples/ or t/ or 
runtime/ -- you'll wonder how our code even works.)

It's a matter of value.  The sky has yet to fall since we removed them from 
the default test set.  Now convince me that these tests are valuable enough 
for release managers to spend their time fixing failures before each release 
and to prevent other people from using DVCS.

-- c