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