[rspec-users] rspec + github == !submodules

[David Chelimsky]

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  
developers.

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