[rspec-devel] Back to one repository?

[David Chelimsky]

On Apr 18, 2008, at 6:27 PM, Pat Maddox wrote:

> Brian, Alex Chaffee and I were talking about the repository layout
> just now.  Alex pointed out that there's a lot of overhead when using
> the rspec project...

Alex and I had an interesting conversation about this last summer at  
the Agile conference. My recollection is that, at that time, his  
primary concerns were about the object structure and life-cycle - that  
it was difficult to understand when things went wrong or how to extend  
it. I think we addressed a lot of his concerns with the major  
refactoring effort that Brian and Aslak undertook last fall, but there  
is certainly more work to do. I'll follow up on some thoughts about  
that in a separate thread.

The point is that my experience thus far is that if Alex is having  
trouble with something, it's probably because it's a serious pain in  
the ass :)

> I've written a bunch of rake tasks to reduce
> that, but even with those there's overhead.  And as we figure out more
> tasks, we'll have to write more rake tasks to automate some of the
> stuff.

Excellent point. Clearly this is an unfortunate maintenance burden.

> For example, if you git:pull and there's a conflict, you have
> to go resolve the conflict and continue the rebase.  Does it make
> sense to write a git:continue command that will examine any repos that
> had a conflict and are in need of a rebase continue?  I'm not sure at
> this point, but it's one of many potential questions.
>
> Alex suggested that we go back to one repository, and change the
> plugin installation process.  Basically the only reason the repos are
> split right now is because there's no way to check out directories,
> and we want people to easily install the rspec and rspec-rails
> plugins.

That's not the only reason. With one repo and the rspec and rspec- 
rails directory up at the root level, developing rspec-rails is a  
PITA. We had rake tasks that copied those two directories down to the  
example rails app. I had tried to make that work w/ symlinks but found  
that the generators did not work when I did that. Not sure if that's a  
rails issue or an rspec issue, but either way it is an unresolved issue.

When we had the rspec_on_rails repo only available down below the  
rails app we got a number of complaints of the low visibility. People  
wanted to grab http://svn.rubyforge.org/rspec/rspec_on_rails instead  
of http://svn.rubyforge.org/rspec/example_rails_app/vendor/plugins/rspec_on_rails 
.

With the repos separated out, the rspec and rspec-rails repos have  
high visibility, are conceptually decoupled, AND can just be installed  
where they need to be for development. These are the pros that must be  
weighed against the cons of developers/contributors having to managing  
multiple repos.

We also need to consider the Ruby developer who doesn't use rails.  
We'd be forcing that user to clone a bunch of stuff they don't need.  
I'm not sure how important an issue that is when weighed against  
everything else, but it is certainly a consideration.

> What if instead of separate repos, we had people put the entire
> codebase under vendor/rspec?  Then they could run a script like
> vendor/rspec/install_plugins that would export the rspec and
> rspec-rails dirs to vendor/plugins.
>
> I realize there will probably be some apprehension given that David
> did a lot of work to split the repos in the first place,

Not relevant.

> and the
> headaches over the past couple days, but I think it's a very good idea
> that's worth considering.

Agree.

> If nothing else, we should keep it in mind
> over the next couple weeks, and see what growing pains we experience
> that might be avoided by a unified repo.

I agree we should keep an eye on this. I have a lot of reservations,  
but remain open to the discussion.

Another consideration is that separating them out has the effect, IMO,  
of reducing the binding of rspec to rails development. There is a  
world of users who believe that rspec is a rails development tool.  
While I'm proud of the fact that rspec-rails has become a serious  
player in the rails space, I'm also excited to see it being used in  
other contexts.

A shining example, even though they're not using our rspec library  
(for good reason - it uses advanced language features that are not  
available in the early phases of the development of a language  
implementation) is rubinius. What they are doing with rspec is  
absolutely astounding. Keeping rspec core as a separate repo increases  
the likelihood of more exciting developments like this outside the  
rails space.

So there are a lot of things to consider here. Looking forward to  
hearing more thoughts on this.

Cheers,
David

> Pat