[ANN] bfts 1.0.0 Released

[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. Edward (Ed) Borasky]

Post by 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.
*** 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!!

[Ryan Davis]

Post by M. Edward (Ed) Borasky
Thank you! Thank you! Thank you! I'm going to go out and buy a new hard
drive and some RAM to celebrate!!

Thanks! I just bought a new mac mini to replace an old loud freebsd
server with a dying hard drive so make sure the RAM works with a mini
and the hard drive is firewire.

Thanks Again!
Ryan

[Jeff Dik]

This is excellent news!

Is the Subversion repository on rubyforge going to be the main
repository for BTFS development?

Thanks,
Jeff

Post by 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.
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
http://rubyforge.org/projects/bfts

[Ryan Davis]

Post by Jeff Dik
This is excellent news!

thanks

Post by Jeff Dik
Is the Subversion repository on rubyforge going to be the main
repository for BTFS development?

Actually no, it is just a mirror of the real repo. I got tired of
people pretending that perforce was too high a hurdle to deal with so
I started mirroring it to svn using svk. I think today I'm going to
write something to replace svk because it is some of the worst and
buggiest perl I've dealt with in a long time and all I need is a
simple 1-way mirror.

[Brian Mitchell]

Post by Ryan Davis

Post by Jeff Dik
This is excellent news!

thanks

Post by Jeff Dik
Is the Subversion repository on rubyforge going to be the main
repository for BTFS development?

Actually no, it is just a mirror of the real repo. I got tired of
people pretending that perforce was too high a hurdle to deal with so
I started mirroring it to svn using svk. I think today I'm going to
write something to replace svk because it is some of the worst and
buggiest perl I've dealt with in a long time and all I need is a
simple 1-way mirror.

Myself being one of those people who are stubborn about using
Perforce, I am glad to hear about a mirror. One tool that I have found
really useful is tailor [1]. It doesn't support Perforce yet but you
might want to look at it if you aren't afraid of Python code.

Though, I would still encourage you to consider a distributed SCM
system (and no -- I don't like svk at all). I get a lot of my free
project time while traveling. I am offline long enough during those
periods that a system that it pays off tremendously. I don't want to
argue other possible differences as it is just a matter of style (to a
point).

Thanks,
Brian.

[1] http://www.darcs.net/DarcsWiki/Tailor

[Ryan Davis]

Post by Brian Mitchell
Myself being one of those people who are stubborn about using
Perforce, I am glad to hear about a mirror. One tool that I have found
really useful is tailor [1]. It doesn't support Perforce yet but you
might want to look at it if you aren't afraid of Python code.

*nod* I'll poke at this. I suspect I need less than 30 lines of ruby
or shell to do this tho.

Post by Brian Mitchell
Though, I would still encourage you to consider a distributed SCM
system (and no -- I don't like svk at all). I get a lot of my free
project time while traveling. I am offline long enough during those
periods that a system that it pays off tremendously. I don't want to
argue other possible differences as it is just a matter of style (to a
point).

ain't gonna happen.

[Ben Bleything]

Post by Ryan Davis
Actually no, it is just a mirror of the real repo. I got tired of
people pretending that perforce was too high a hurdle to deal with so
I started mirroring it to svn using svk. I think today I'm going to
write something to replace svk because it is some of the worst and
buggiest perl I've dealt with in a long time and all I need is a
simple 1-way mirror.

I don't think it's too high a hurdle, it's just an unnecessary one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.

I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.

Ben

[Ryan Davis]

Post by Ben Bleything
I don't think it's too high a hurdle, it's just an unnecessary
one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.

how about: subversion blows multicolored chunks?

Post by Ben Bleything
I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.

see above.

[Ben Bleything]

Post by Ryan Davis
how about: subversion blows multicolored chunks?

plz elaborate? It works fine for me and lots of other folks. Again,
I'm not arguing with your opinion, I'm just curious. We used p4 at an
old job of mine and everyone loved it. It's just not as easily
accessable as svn.

Ben

[Ryan Davis]

This post might be inappropriate. Click to display it.

[Ben Bleything]

Post by Ryan Davis
hrmmm... to start: slow as dirt, user unfriendly, merging is a bitch,
and prone to corruption. The first two really really really bother me
on a daily basis. The third not as much but is very important to me.
The last one is absolutely unacceptable.

I've not noticed it to be slow or unfriendly, but I learned version
control on CVS so maybe its just that I'm used to crap. Merging *is* a
bitch, I'll give you that.

As for corruption, using an fsfs backend makes it pretty hard to corrupt
a repository except by user error. I've never seen an fsfs-backed repo
get corrupted.

Post by Ryan Davis
How is p4 less accessible? Easy download and works on nearly any
platform under the sun.

To take my svn and your p4 repositories as an example, and assuming
darwinports, and understanding that my frustration comes from the fact
that I often want to look at your code without installing it:

my svn
------
- sudo port install subversion
- svn co http://svn.bleything.net/somerepo

your p4
-------
- sudo port install perforce (okay so this part is the same
- The 7ish steps listed at http://zenspider.com/ZSS/Process/Perforce.html,
including one where I wait for you to set up my user

There's also the whole "lock individual files with 'p4 edit'" thing,
which I admit is purely personal preference, but I like the svn workflow
better.

Again, not bad, just different... but in a way that does make it a pain
to adopt.

Ben

[Ryan Davis]

Post by Ben Bleything

Post by Ryan Davis
hrmmm... to start: slow as dirt, user unfriendly, merging is a bitch,
and prone to corruption. The first two really really really bother me
on a daily basis. The third not as much but is very important to me.
The last one is absolutely unacceptable.

I've not noticed it to be slow or unfriendly, but I learned version
control on CVS so maybe its just that I'm used to crap. Merging *is* a
bitch, I'll give you that.

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!)

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

Post by Ben Bleything
As for corruption, using an fsfs backend makes it pretty hard to corrupt
a repository except by user error. I've never seen an fsfs-backed repo
get corrupted.

o rly? What backend does rails use?

Post by Ben Bleything
my svn
------
- sudo port install subversion
- svn co http://svn.bleything.net/somerepo
your p4
-------
- sudo port install perforce (okay so this part is the same
- The 7ish steps listed at http://zenspider.com/ZSS/Process/
Perforce.html,
including one where I wait for you to set up my user

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.

The svn mirror is a compromise. We'll get diffs

Post by Ben Bleything
There's also the whole "lock individual files with 'p4 edit'" thing,
which I admit is purely personal preference, but I like the svn workflow
better.

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

Post by Ben Bleything
Again, not bad, just different... but in a way that does make it a pain
to adopt.

bah

[Ben Bleything]

Post by Ryan Davis
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

Post by Ryan Davis
Oh! And try diffing while ignoring whitespace! HAHAHAHA Real friendly
there!

also granted

Post by Ryan Davis
o rly? What backend does rails use?

No idea. If it's at rubyforge, fsfs apparently.

Post by Ryan Davis
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

Post by Ryan Davis
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.

Post by Ryan Davis

Post by Ben Bleything
Again, not bad, just different... but in a way that does make it a
pain to adopt.

bah

I agree.

Ben

[Bill Kelly]

Post by Ryan Davis

Post by Ben Bleything
There's also the whole "lock individual files with 'p4 edit'" thing,
which I admit is purely personal preference, but I like the svn workflow
better.

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

[Austin Ziegler]

Post by Bill Kelly
Interesting. The kind of Communication I remember as the
"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

[Ben Bleything]

Post by Ryan Davis

Post by Ben Bleything
- The 7ish steps listed at http://zenspider.com/ZSS/Process/
Perforce.html,
including one where I wait for you to set up my user

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

[Tom Copeland]

Post by Ben Bleything
As for corruption, using an fsfs backend makes it pretty hard
to corrupt a repository except by user error. I've never
seen an fsfs-backed repo get corrupted.

FWIW, all the RubyForge svn repos are fsfs.

Yours,

Tom

[Tom Pollard]

Post by Ryan Davis

Post by Ben Bleything
I don't think it's too high a hurdle, it's just an unnecessary one. I'm
sure you've got good reasons for preferring it to svn, but I don't know
what they are.

how about: subversion blows multicolored chunks?

Post by Ben Bleything
I'd be interested to hear why you prefer your own p4 repo to using
RubyForge's svn.

see above.

Sure, ruby-talk generates a lot of traffic, but I stay subscribed to
enjoy the scintillating repartee...

Tom

[Tim Pease]

Post by 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.

Ryan, is this going to be a one developer project? 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?

TwP

[Ryan Davis]

Post by Tim Pease

Post by 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.

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

Oh hell no.

Post by Tim Pease
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.

[Charles Oliver Nutter]

Post by Ryan Davis

Post by Tim Pease
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.

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. Edward (Ed) Borasky]

Post by Charles Oliver Nutter

Post by Ryan Davis

Post by Tim Pease
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.

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.

[Charles Oliver Nutter]

Post by M. Edward (Ed) Borasky
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.

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

[Chris Carter]

Hi Ryan,

Who/Where should I contact with failing test information?

--
Chris

Post by 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.
*** 1.0.0 / 2005-10-28
+ 1 major enhancement
+ Birthday!
http://rubyforge.org/projects/bfts

[Ryan Davis]

Post by Chris Carter
Who/Where should I contact with failing test information?

http://rubyforge.org/projects/bfts

file a bug pls. that way we can track em.

[Daniel Berger]

Post by 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.

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

[Ryan Davis]

Post by Daniel Berger
Feel free to grab whatever you want from ruby_test (in SCM as part of
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.

[Daniel Berger]

Post by Ryan Davis

Post by Daniel Berger
Feel free to grab whatever you want from ruby_test (in SCM as part of
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