[rspec-users] rspec + github == !submodules
bryansray at gmail.com
Thu Apr 17 10:28:12 EDT 2008
Great information, David.
Sounds like a useful blog post!
On Thu, Apr 17, 2008 at 7:49 AM, David Chelimsky <dchelimsky at gmail.com>
> On Apr 17, 2008, at 7:11 AM, David Chelimsky wrote:
> > On Apr 17, 2008, at 5:20 AM, Jonathan Leighton
> > <j at jonathanleighton.com> wrote:
> >> Hi David,
> >> Is there any chance you could elaborate on the problems please, so
> >> that
> >> other projects can make an informed decision whether to use
> >> submodules
> >> or not?
> > There is always a chance :)
> What I learned was that submodules are great for things like consuming
> plugins in your rails projects, but not so great for a development
> effort in multiple people are pushing and pulling to multiple
> repositories with dependencies and no multi-project transaction support.
> The parent repository depends on specific versions of the subs. As
> you're making changes in your local repos, the last thing you do is
> commit the parent with the references to the new versions of the subs.
> Every time you make a change to any of the subs you have to commit a
> change to the parent. These changes are useful as documentation if
> you're updating a plugin to the latest release. Not that useful if the
> log is polluted with these for every commit to every submodule.
> When you pull, you pull the parent first, and then use git-submodule
> to pull the correct versions of the subs. The parent is in control of
> the situation and it somewhat guarantees that you're getting all the
> right stuff. This is GREAT for consumers, but problematic for
> contributors. And even then, if consumers are pulling from a
> development branch while developers are pushing to it, then consumers
> might run into problems.
> Let's say you're doing a pull while I'm doing a push. If I push the
> parent first, and I push it before you do, there is a chance that when
> you go to pull the subs those versions of the subs might not be there
> yet. Conversely, if I push the subs first and you grab an old parent,
> you'll be pulling old subs. No problem when you're pulling, but it's
> going to create problems when you go to push because you're that much
> further down the history.
> Of course, these problems exist even when you're dealing with a single
> repository on a team that believes in frequent commits, continuous
> integration, etc. And just by virtue of the fact that we have several
> repos with dependencies means that we're going to run into conflicts
> now and then. It just seems that the explicit references from parent
> to children adds a layer of complexity to this for both consumers and
> This all make sense?
> >> Cheers,
> >> Jon
> >> On Wed, 2008-04-16 at 22:39 -0400, David Chelimsky wrote:
> >>> Hey all,
> >>> We ran into some problems last night with the repos up at github. We
> >>> initially thought it was a git-submodules bug. We learned that it
> >>> was
> >>> something else, but in the process of trying to find the source of
> >>> the
> >>> bug, we learned a few things about git-submodules and have decided
> >>> that it creates an unfortunate set of complications and dependencies
> >>> for a development effort like ours.
> >>> To that end, we have simplified. No more submodules. To update, do
> >>> the
> >>> following:
> >>> cd rspec-dev
> >>> git pull
> >>> rake git:update
> >>> See http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches
> >>> for more info.
> >>> Cheers,
> >>> David
> rspec-users mailing list
> rspec-users at rubyforge.org
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning."
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users