[ANN] bfts 1.0.0 Released

R

Ryan Davis

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.

Changes:

*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!

http://rubyforge.org/projects/bfts
 
M

M. Edward (Ed) Borasky

Ryan said:
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.

Changes:

*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!

http://rubyforge.org/projects/bfts
Thank you! Thank you! Thank you! I'm going to go out and buy a new hard
drive and some RAM to celebrate!!
 
B

Ben Bleything

Try to figure out how to emulate 'p4 describe' and make it just as
fast as perforce. For that matter, 'p4 filelog', 'p4 changes', and
'p4 opened -a' (haha, you can't do that one!)
granted

Oh! And try diffing while ignoring whitespace! HAHAHAHA Real friendly
there!

also granted
o rly? What backend does rails use?

No idea. If it's at rubyforge, fsfs apparently.
Yup. HUGE hurdle there... and I thought working with the brilliance
that is my code would be worth that. :p I suppose I could create a
script to automate this, but it is a one time shot so I don't see it
being worth that. I guess I should consider it a bozo filter. Those
people that seriously want to work on our projects will jump through
our hoops. Those that don't, won't.

Not a hurdle. You just asked why it's harder to adopt... 8 steps vs. 2
steps... even if those 8 steps are easy (which they are!). Speaking of
which, look for an email from me soon to get set up :p
That is a feature and a damned good one I wish svn had. "Oh? Eric is
working on this file? Maybe I should talk to him before I go ripping
stuff up!" Communication. What software development is REALLY about...

Yup, again, personal preference. I don't miss it because I've never
needed it. Ask me again once I have and I'm sure I'll be on your side.

I agree.

Ben
 
R

Ryan Davis

Ryan, is this going to be a one developer project?

Oh hell no.
You have already
demonstrated your +60 "keyboard of coding might", but this still seems
like a huge project for a single individual. Are you looking for
worker bees to help out on this one?

PLEASE. +60 VORPAL keyboard of coding might!

Yes, we'd love other contributors.
 
B

Bill Kelly

From: "Ryan Davis said:
That is a feature and a damned good one I wish svn had. "Oh? Eric is
working on this file? Maybe I should talk to him before I go ripping
stuff up!" Communication. What software development is REALLY about...

Interesting. The kind of Communication I remember as the
staple of locking-style VC projects went something like this:
"Bob, I need access to frobozz.cpp, will you be checking in
soon?" "Well, I haven't changed frobozz very much, but if I
check it in it won't compile for you. I can't check it in until
I finish with XYZZY, then I'll check in all these files at once."
"Oh... well I guess I'll just modify my copy locally and merge
manually, as usual."

I *never* want to go back to that. Maybe this isn't so much
of an issue with p4, since it apparently _does_ know how to
merge changes? (The old locking-style VC systems I used didn't
know about merging at all.)

Just wondering,

Bill
 
C

Charles Oliver Nutter

Ryan said:
PLEASE. +60 VORPAL keyboard of coding might!

Yes, we'd love other contributors.

I understand SCM preference, but this is probably the primary reason
projects choose SVN or CVS over anything else. Your average contributor
is going to be far more likely to know SVN or CVS than P4 or anything
else. Also, direct tool support for those tends to be greater because
they're 100% free and pervasive in the OSS community.

So the tradeoff for your SCM of preference (P4) is ease of contribution.
If that's not as important, no problem. It would never work for JRuby,
for example, where we have something like 20 external contributors
throwing patches at us and even more running off trunk.
 
M

M. Edward (Ed) Borasky

Charles said:
I understand SCM preference, but this is probably the primary reason
projects choose SVN or CVS over anything else. Your average contributor
is going to be far more likely to know SVN or CVS than P4 or anything
else. Also, direct tool support for those tends to be greater because
they're 100% free and pervasive in the OSS community.

So the tradeoff for your SCM of preference (P4) is ease of contribution.
If that's not as important, no problem. It would never work for JRuby,
for example, where we have something like 20 external contributors
throwing patches at us and even more running off trunk.

I'd be happy if the CVS and SVN folks would settle their war so I don't
need to learn both. :)

Seriously, though, I have two projects on RubyForge, one in CVS and the
other in SVN. Don't ask me why; I don't know. The only one I use
actively is the CVS one.
 
C

Charles Oliver Nutter

M. Edward (Ed) Borasky said:
I'd be happy if the CVS and SVN folks would settle their war so I don't
need to learn both. :)

Seriously, though, I have two projects on RubyForge, one in CVS and the
other in SVN. Don't ask me why; I don't know. The only one I use
actively is the CVS one.

I can't say I'm a huge fan of either, but they're no-brainers to use for
open source. Not with any other SCM could I just toss an offhand URL out
and know that people would be able to handle everything. Really all I
need to do to get someone involved is say "it's in SVN, here's the URL".
Done and done. That's a huge advantage for getting folks involved.

And as slow as it is, the DAV-based SVN servers are just about the
easiest ones to work with. Not only you can use non-SVN tools to pull
files if necessary (i.e. mount as a folder if you wish) but you can poke
around in an ordinary web browser. Unpleasant for day-to-day commits,
but trivial to make source available to a wide audience.
 
A

Austin Ziegler

Interesting. The kind of Communication I remember as the
staple of locking-style VC projects went something like this:
"Bob, I need access to frobozz.cpp, will you be checking in
soon?" "Well, I haven't changed frobozz very much, but if I
check it in it won't compile for you. I can't check it in until
I finish with XYZZY, then I'll check in all these files at once."
"Oh... well I guess I'll just modify my copy locally and merge
manually, as usual."

I *never* want to go back to that. Maybe this isn't so much
of an issue with p4, since it apparently _does_ know how to
merge changes? (The old locking-style VC systems I used didn't
know about merging at all.)

It isn't an issue with p4. We use it at work. Even if Perforce didn't
offer free licenses for open source work, it's worth every freakin'
penny.

-austin
 
C

Cameron McBride

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.
 
D

Daniel Berger

Ryan said:
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
 
D

Daniel Berger

Ryan said:
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
 
B

Ben Bleything

Yup. HUGE hurdle there... and I thought working with the brilliance
that is my code would be worth that. :p I suppose I could create a
script to automate this, but it is a one time shot so I don't see it
being worth that. I guess I should consider it a bozo filter. Those
people that seriously want to work on our projects will jump through
our hoops. Those that don't, won't.

As it turns out, this apparently is a hurdle. The day this thread was
new I sent you an email asking you to set me up. Haven't heard back
yet.

The email probably got lost, which obviously isn't anyone's fault, but
if it were in svn on RubyForge (for instance) we wouldn't have this
problem.

Ben
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top