Discussion:
[ANN] bfts 1.0.0 Released
(too old to reply)
Ryan Davis
2006-10-31 01:07:28 UTC
Permalink
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
2006-10-31 01:25:46 UTC
Permalink
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
2006-10-31 18:06:16 UTC
Permalink
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
2006-10-31 13:11:14 UTC
Permalink
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
2006-10-31 18:08:32 UTC
Permalink
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
2006-10-31 19:00:48 UTC
Permalink
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
2006-10-31 19:07:33 UTC
Permalink
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
2006-10-31 19:01:29 UTC
Permalink
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
2006-10-31 19:08:23 UTC
Permalink
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
2006-10-31 19:17:35 UTC
Permalink
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
2006-10-31 19:32:04 UTC
Permalink
Post by 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.
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.

How is p4 less accessible? Easy download and works on nearly any
platform under the sun.
Ben Bleything
2006-10-31 19:46:39 UTC
Permalink
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
2006-10-31 19:56:54 UTC
Permalink
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
2006-10-31 20:17:20 UTC
Permalink
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
2006-10-31 20:58:26 UTC
Permalink
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
2006-11-01 16:21:27 UTC
Permalink
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
--
Austin Ziegler * ***@gmail.com * http://www.halostatue.ca/
* ***@halostatue.ca * http://www.halostatue.ca/feed/
* ***@zieglers.ca
Ben Bleything
2006-11-16 18:18:17 UTC
Permalink
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
2006-10-31 20:06:51 UTC
Permalink
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
2006-10-31 19:37:12 UTC
Permalink
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
2006-10-31 19:55:08 UTC
Permalink
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
2006-10-31 20:20:59 UTC
Permalink
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
2006-10-31 22:51:49 UTC
Permalink
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.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
***@headius.com -- ***@sun.com
M. Edward (Ed) Borasky
2006-11-01 04:52:24 UTC
Permalink
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
2006-11-01 09:55:57 UTC
Permalink
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.
--
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java @ headius.blogspot.com
Help spec out Ruby today! @ www.headius.com/rubyspec
***@headius.com -- ***@sun.com
Cameron McBride
2006-11-01 16:56:12 UTC
Permalink
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.
Daniel Berger
2006-11-01 17:14:35 UTC
Permalink
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
2006-11-01 18:42:25 UTC
Permalink
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
2006-11-14 17:40:07 UTC
Permalink
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
Ryan Davis
2006-11-01 18:35:01 UTC
Permalink
Who/Where should I contact with failing test information?
http://rubyforge.org/projects/bfts

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