Great information, David. Sounds like a useful blog post!
On Thu, Apr 17, 2008 at 7:49 AM, David Chelimsky <[EMAIL PROTECTED]> wrote: > 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 > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- Bryan Ray http://www.bryanray.net "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."
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
