On Apr 17, 2008, at 7:11 AM, David Chelimsky wrote: > On Apr 17, 2008, at 5:20 AM, Jonathan Leighton > <[EMAIL PROTECTED]> 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 _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
