ok, since this thread has veered it’s head toward SCMs, I’m also
throwing in my irrelevant opinion. Git has been a most welcome
addition to my workflow: distributed, direct, easy branching and (so
far) good merging. Oh, and it has git-cvsserver that serves as a
two-way bridge for those that insist on CVS (albeit for a simple
subset of CVS commands).
It can be served read-only from an http mounted directory (although
not efficiently), and comes with a perl CGI script to view repos.
Cameron
p.s. I agree with the multicolored chunks bit.
Ryan D. wrote:
bfts version 1.0.0 has been released!
http://rubyforge.org/projects/bfts
BFTS is a branch of rubicon with the intent of auditing all of rubicon
against the latest version of 1.8.x, stripping all the cruft, and
getting everything up to date again. rubicon is dead and the authors
have shown no interest in getting things moving again. BFTS hopes to
fix that.
Ryan,
Feel free to grab whatever you want from ruby_test (in SCM as part of
the ‘shards’ project):
http://rubyforge.org/projects/shards/
Regards,
Dan
On Nov 1, 2006, at 9:15 AM, Daniel B. wrote:
Feel free to grab whatever you want from ruby_test (in SCM as part of
the ‘shards’ project):
http://rubyforge.org/projects/shards/
If I do, and you are happy with the merger, will you delete yours?
Yes, I’m trying for some unification here.
On Nov 1, 2006, at 7:02 AM, Chris C. wrote:
Who/Where should I contact with failing test information?
http://rubyforge.org/projects/bfts
file a bug pls. that way we can track em.
Ryan D. wrote:
On Nov 1, 2006, at 9:15 AM, Daniel B. wrote:
Feel free to grab whatever you want from ruby_test (in SCM as part of
the ‘shards’ project):
http://rubyforge.org/projects/shards/
If I do, and you are happy with the merger, will you delete yours?
Sorry for the late reply…
I’m afraid I’m unwilling to budge on the “one method, one file”
organization for the tests, at least for core Ruby. I’m also not sure
what your feelings are regarding benchmarks, which I use as a form of
high iteration testing as well as a way to check for pathological
slowdowns.
I think you’ll find that sticking all class and instance methods for a
given class in one file will become unmanageable over time, especially
when you consider platform specific tests, $SAFE tests, etc. IMHO,
separating the methods makes the tests easier to manage and will make
it easier for other people to contribute test cases.
Regards,
Dan