I've also had less-than-ideal experiences with git submodules. They seem to me to scale poorly as the team size increases.
Rick On Mon, Jan 31, 2011 at 10:46 AM, Jesse Wolfe <[email protected]> wrote: > I second that git submodules seem to be flaky; I've found it surprisingly > hard to just correctly, consistently update submodules. > > And I agree that it can be difficult to safely update code that other > projects depend on - but if we do it right, this could be a forcing function > that causes us to make sure our libraries have stable interfaces. > I suppose this is a good time to mention that continuing to beef up our > automated build/test infrastructure will make this easier to get right. > > ~Jesse > > On Mon, Jan 31, 2011 at 3:19 AM, David Schmitt <[email protected]> wrote: >> >> On Mon, 31 Jan 2011 00:19:11 -0800, Luke Kanies <[email protected]> >> wrote: >> > Hi all, >> > >> > I think there are a few classes or subsystems in Puppet that could, and >> > maybe should, be extracted into separate projects so they can be more >> > widely used; at worst, they could at least be shared by our other >> projects. >> > I'd love to be able to pull functional bits out of Puppet and use them >> > elsewhere -- e.g., I'd love to have mcollective, Puppet, PMT, and Facter >> > all share the code that creates their applications. >> > >> > I'm thinking of, at the least, our graphing stuff and the application >> > classes (plus the Interface classes I'm working on[1]). >> > >> > The problem with doing this, of course, is that it introduces that >> > external code as a dependency, which doesn't really work. >> > >> > I expect the only real choices are to list them as dependencies, or do a >> > kind of vendoring, like we're doing with Event::Loop and JSON. >> > >> > How do other projects solve this? Does anyone have any experience doing >> > so? >> >> Two datapoints: >> >> 1) distro packages will need to split out the dependencies to reap the >> benefits of code sharing in the package dependencies too. This in turn >> requires that current versions of the apps always use (work together with) >> the same version of the library. >> >> >> 2) Ayende recommends git subtree: >> http://ayende.com/Blog/archive/2011/01/10/git-subtree.aspx >> >> I've no personal experience with it though. The experience sounds good >> though, since: >> > it is only me that have to use this, everyone else can just work with >> the usual git tools, and not have to be aware that I am sharing code >> between projects in this manner. >> >> >> >> Best Regards, David >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/puppet-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
