Closed (fixed)
Project:
Drupal.org customizations
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
16 Jan 2011 at 17:26 UTC
Updated:
28 Aug 2014 at 04:10 UTC
Jump to comment: Most recent
Comments
Comment #1
eliza411 commentedsdboyer, not sure how you're grouping the file system issues, but would you update this when that issue gets opened?
Comment #2
dwwSeems like this is blocked on #1038404: Determine an approach to managing git repositories on disk for now. Perhaps others.
Comment #3
sdboyer commentedNot blocked on that, actually. For now the scripts are perfectly fine relying on the local filesystem path contained in $repo->root. We won't need to revisit for several months after launch, at least. Untagging accordingly.
Comment #4
drummComment #5
drummhttp://cgit.drupalcode.org/drupalorg/tree/drupalorg_project/plugins/rele... is the code I'll be updating.
Comment #6
damien tournoud commented@drumm: if you want to still use
git archive, the easiest path is probably to:git archive --remote=<URL> ..., where<URL>is a simple Git-protocol URL (ie. one withgit://);git-daemonon util so that it allows theupload-archiveservice.There are two alternative paths, but I don't think they are desirable:
--shallow) and export the archive from there;Comment #7
drummI think I may go with a variation on
There are some more Git operations that happen for branch packaging in
computeRebuildVersion(). My testing shows that works with a--depth 0clone.(I'm also not eager to change the Git daemon config.)
Comment #8
drummActually,
--depth 1is what I would want for a shallow clone, and it doesn't helpcomputeRebuildVersion(). That code looks like it needs a full clone locally, or at least the history back to the most recent tag on the branch. We will need to do a full clone anyway.Comment #10
drummComment #11
drummNow deployed.