hi, for those of us that use drush make through aegir for creating our dev installations, I would be helpful to allow us to set --working-copy also in a make file as well as on the commandline.. here is a patch that does this for the different VC download methods.

CommentFileSizeAuthor
#18 working-copy-958844.patch3.74 KBjoestewart
#17 working-copy-958844.patch5.06 KBjoestewart
#4 drush_make-working-copy-in-makefile_function.patch3.16 KByareckon
drush_make-working-copy-in-makefile.patch2.91 KByareckon

Comments

yareckon’s picture

yareckon commented
Title: PATCTH: Allow [working-copy] in makefile as well as on commandline » PATCH: Allow [working-copy] in makefile as well as on commandline
yareckon’s picture

yareckon commented

this takes the syntax:
projects[projectname][download][working-copy] = TRUE

Anonymous’s picture

Anonymous (not verified) commented

sub. really would love this feature

yareckon’s picture

yareckon commented
StatusFileSize
new drush_make-working-copy-in-makefile_function.patch3.16 KB

Broke checking this option out into a function

Testing on other version control systems than git has not yet been done, but we are just changing how we read in this option before we get into the VC specific code.

dmitrig01’s picture

dmitrig01 commented

I would just set $download['working-copy'] in whatever function passes stuff into there

dmitrig01’s picture

dmitrig01 commented
Status: Needs review » Needs work
dmitrig01’s picture

dmitrig01 commented

additionally, i would introduce an options array in the root level of the makefile, for example options[working-copy] = true. I may even take a shot at this myself.

eft’s picture

eft commented

subscribing

sime’s picture

sime
any/any
Location Melbourne
commented

I would like --working-copy to be settable in the makefile, because in my situation I am making platforms from aegir gui.

susie’s picture

susie commented

subscribing

steven jones’s picture

steven jones commented

Subscribington.

chaps2’s picture

chaps2 commented

Patch works for cvs and svn as well as git. If using with svn you may need to add this...

projects[projectname][download][force] = FALSE

...as detailed here #1001634: svn --working-copy doesn't work in RHEL.

mxmilkiib’s picture

mxmilkiib commented

subscribe

mcdruid’s picture

mcdruid commented

subscribe

anarcat’s picture

anarcat commented

+1

(death to +1)

Anonymous’s picture

Anonymous (not verified) commented

Applied patch in #4 to 6.x-3.x branch. 1 hunk failed at line 601. That failure didn't impact me since I'm using git and this patch's functionality works great for that.

joestewart’s picture

joestewart commented
Status: Needs work » Needs review
StatusFileSize
new working-copy-958844.patch5.06 KB

patch rolled for 3.x but should apply back to 2.x OK.

Addressed #5 by setting the option in __construct().

Addressed #7 in [#1206340: introduce an options array in the root level of the makefile]

joestewart’s picture

joestewart commented
StatusFileSize
new working-copy-958844.patch3.74 KB

argh. Last patch had the changes for [#1206340: introduce an options array in the root level of the makefile] too.

trying again.

danepowell’s picture

danepowell commented

sub- would love to see this, so that I can use git_deploy in conjunction with aegir

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs review » Needs work

If some makefile sets projects[projectname][download][working-copy] = TRUE, and projectname is built as part of an install profile on drupal.org, then I think this patch would cause drupal.org to needlessly pull down a working copy of the submodule when building an install profile.

I would recommend abandoning this patch in favor of #1206340: introduce an options array in the root level of the makefile, which now contains a proposal that also supports projects[projectname][download][options][working-copy] = TRUE (in addition to options[working-copy] = TRUE), while also giving the original caller control over what overrides should be allowed.

yareckon’s picture

yareckon commented
Status: Needs work » Fixed

I support the work going on over in your thread. Let's close this in favor of your approach.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.