This is probably me contradicting myself, but I've had to install this thing like 1200 times tonight and it's really annoying how long it takes.

As one flaming example, I see no reason we have to clone jQuery UI itself from Git. Twice. Similarly, we don't need a Git clone of Drupal core, though a dev version or #1089820: We should use Pressflow would be good, since we want notices turned on.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

naxoc’s picture

I agree. Trying to test #1089820: We should use Pressflow has had me wait something like 9435868353456346 minutes. I'll boil down the makefile for the contrib stuff and then move on to #1089820: We should use Pressflow.

naxoc’s picture

Status: Active » Needs review
FileSize
6.46 KB

Here is a patch that speeds things up a bit. I don't have a clear idea about which modules we are hacking on, but I took a wild guess. Here is a list of what the patch changes:

Not in Git anymore:

  • apachesolr
  • apachesolr_multisitesearch
  • autoload
  • beanstalkd
  • codefilter
  • comment_alter_taxonomy
  • comment_upload
  • ctools
  • dbtng
  • diff
  • drupal_queue
  • drupalorg
  • google_admanager
  • google_analytics
  • homebox
  • image
  • jquery_ui
  • multiple_email
  • path_redirect
  • tracker2
  • views
  • views_bulk_operations
  • views_content_cache
  • views_field_view
  • waiting_queue
  • devel
  • install_profile_api
  • libraries

Externals not in Git anymore:

  • jquery-ui

I couldn't figure out how to just download from github and not use git. The urls redirect and I think cUrl gives up on that in drush make. I found an alternative url for jquery-ui, but glip is still checked out from github.

Still in Git:

  • project
  • project_git_instructions
  • project_issue
  • sshkey
  • versioncontrol
  • versioncontrol_git
  • versioncontrol_project
  • git_deploy
dww’s picture

The Git clone itself is the bottleneck here? This seems like a dangerous and IMHO pointless road to go down. ;) I'm fine with not checking out jquery UI twice, but I really don't think we're saving much by trying to avoid Git entirely. drush already has support for git reference caching. I guess drush make doesn't? Evil that those are different code paths. I'd rather see effort going into fixing that than trying to not use Git clones for a dev site install profile like this.

-1 from me.

naxoc’s picture

FileSize
1.4 KB

OK, here is a patch that (still) fetches jquery-ui twice, but at least does it without git. The fetching it twice I don't really know what to do about though, but it should be fast.

All the other projects are back in git.

naxoc’s picture

Should we just close this issue? The patch will probably optimize with less ms. than humans can register.

webchick’s picture

No, I'd like to keep this open a bit longer.

IMO yes, git is actually the bottleneck. A git clone for core is 46.1 MB. A drush dl of core is 4.8 MB.

Sheldon Rampton’s picture

Hm, I get the feeling that Drupalistas are still struggling to get their heads around the finer points of git, in particular when managing multiple retrievals from different git repositories. I confess that I'm a git newbie myself. I imagine git is the bottleneck because of the overhead involved in storing the version history as well as the current version of everything, and with Drupal core in particular, there's a lot of history. But if you fetch stuff without git, doesn't that make it harder to subsequently create and submit patches?

Is there/should there be a way to give people a choice between git clone vs. simple downloads when doing a drush dl or drush make? I can see use cases for either option. If you're planning to submit patches to any of the modules in the installation profile, you probably want git clones so you can diff and patch. In my particular use case, I'm actually planning to build a website that will be "inspired by" Drupal.org but will be a separate website entirely, so it's more like a fork than a branch, and I'd therefore prefer to just have downloads of all the code that I can use to initialize my own separate repository.

webchick’s picture

This is a development profile and should just use Git for anything likely to be hacked on, as mentioned in the OP, since the entire point is to provide patches to upstream projects.

However, I can't think of any change we'd allow on d.o that would also hack core. Neither any of the libraries like jQuery, and at least some of the other supporting modules (e.g. image). But core is the biggest reason the profile takes so long to acquire, so even if we just flipped that to a drush dl instead of a git checkout that would do a lot.