On Thu, Apr 17, 2008 at 9:01 AM, Jonathan Leighton <[EMAIL PROTECTED]> wrote: > On Thu, 2008-04-17 at 08:49 -0400, David Chelimsky wrote: > > This all make sense? > > Ok, I have to confess I haven't been paying that much attention to the > way things are or were set out on github, so let me see if I'm fully > understanding what you're saying... > > Was "rspec" previously split up into several repositories, with a > "parent" repository which contained the other repositories as > submodules? So you are essentially saying that it is a bad idea to split > one single project into a number of pieces and manage that project > through submodules? However, you do consider submodules to be a good > idea if you are using and wish to track third-party upstream code, for > example plugins in a Rails project?
RSpec was split into four repos...and it still is actually. But originally the rspec-dev project was a superproject that included the other three as submodules. The problem with submodules is if two people are making changes to the submodules at the same time. Let's say I work on the rspec submodule, and my final commit is abc123. You work on the rspec submodule as well and your final commit is def456. The superproject tracks the head of each submodule, meaning we each need to commit a reference to the heads of rspec. At some point you pull from my...and the incoming commits say that the head is abc123, but you say def456. merge conflict. Not a big deal, since you have all the latest code, so you can safely point it at def456. But it's a bit of a hassle because you have to do that every single time. I don't actually know what all the potential problems are, but beyond just the hassle, it seems very easy for someone to make a mistake, causing a lot of headaches. We still have stuff split up, but we realized there's no reason for the rspec-dev repo to track the others as submodules. We wrote a rake task to check out all the other repos beneath the rspec-dev dir. It's basically the exact same setup, but without the submodule tracking. And it avoids any problems with submodules, because it's all just standard git push/pull/merge stuff. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
