Bfts 1.0.0 Released

Ruby
1

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

2

Ryan D. wrote:

Changes:

*** 1.0.0 / 2005-10-28

Thank you! Thank you! Thank you! I’m going to go out and buy a new hard
drive and some RAM to celebrate!!

3

This is excellent news!

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

Thanks,
Jeff

4

On Oct 30, 2006, at 5:25 PM, M. Edward (Ed) Borasky wrote:

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

5

On Oct 31, 2006, at 5:11 AM, Jeff D. wrote:

This is excellent news!

thanks

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.

6

On Wed, Nov 01, 2006, Ryan D. wrote:

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

7

On Oct 31, 2006, at 11:00 AM, Brian M. wrote:

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.

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.

8

On Oct 31, 2006, at 11:01 AM, Ben B. wrote:

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?

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

see above.

9

On Wed, Nov 01, 2006, Ryan D. wrote:

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

10

On 10/31/06, Ryan D. [email protected] wrote:

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] Darcs - RelatedSoftware/Tailor

11

On Oct 31, 2006, at 2:08 PM, Ryan D. wrote:

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

12

On Oct 31, 2006, at 11:17 AM, Ben B. wrote:

On Wed, Nov 01, 2006, Ryan D. wrote:

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.

13

On Wed, Nov 01, 2006, Ryan D. wrote:

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.

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

your p4

  • sudo port install perforce (okay so this part is the same
  • The 7ish steps listed at
    zenspider.com | by ryan davis,
    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

14

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

15

On Oct 31, 2006, at 11:55 AM, Tim P. wrote:

fix that.

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.

16

On 10/30/06, Ryan D. [email protected] 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, 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

17

Charles Oliver N. wrote:

Yes, we’d love other 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. :slight_smile:

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.

18

M. Edward (Ed) Borasky wrote:

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

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.

19

Ryan D. wrote:

On Oct 31, 2006, at 11:55 AM, Tim P. wrote:

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.

20

Hi Ryan,

Who/Where should I contact with failing test information?

–
Chris