I cannot manage to use the following alias settings for the core-rsync command:
- source-command-specific
- target-command-specific
This is even more surprising because they are explicitly described in "drush topic docs-aliases".

After digging into the code, it seems that these prefixes are simply not handled by the rsync command (I tried to compare with sql-sync that works correctly).

You can try the following configuration:

$aliases['src'] = array(
  'uri'    => 'default',
  'root'   => '/path/to/src',
  'source-command-specific' => array (
    'core-rsync' => array (
      'delete' => true,
      'exclude-paths' => '.htaccess',
    ),
  ),
);

$aliases['dst'] = array(
  'uri'    => 'default',
  'root'   => '/path/to/dst',
);

The command drush rsync @src @dst -s doesn't take into account the --delete option.
If you replace the source-command-specific option by command-specific, it works as expected.

Comments

mdhooge’s picture

mdhooge commented

The problem is also present in 4.1 & 4.2.

greg.1.anderson’s picture

greg.1.anderson commented
Assigned: Unassigned » greg.1.anderson
Category: bug » feature

Yes, this is a good idea.

mdhooge’s picture

mdhooge commented

Hello Greg,

I don't mind that you recategorized my bug report as a feature request. But since this feature is already explicitly mentioned at line #173 of example.aliases.drushrc.php, I thought it should be available ;-)

However, even without that feature, I couldn't live any longer without rsync & aliases!

greg.1.anderson’s picture

greg.1.anderson commented
Category: feature » bug

Bug or a feature, that is the question. Either way, I agree it is important and will try to find time to implement it soon. My comment in example.aliases.drushrc.php was clearly overly optimistic, because I never the code to go with (half of) it. :) Oops!

drew reece’s picture

drew reece commented

You can use just 'command-specific' options to get the values applied for using rsync as a workaround at the moment. Probably less than ideal depending on your setup.

The site-alias command is also stripping the 'command-specific' records from a local alias, I wonder if it is related. I'm using drush 4.2.

drush sa @myalias will only show the source-command-specific or target-command-specific entries. I have both core-rsync & sql-sync settings in the xx-command-specific sections.

willieseabrook’s picture

willieseabrook commented

I just read the docs, tried to use this feature, found out its not actually implemented yet, and found this issue.

Would be a great addition!

Subscribing.

Oh and is this *really* 5.x-dev?

greg.1.anderson’s picture

greg.1.anderson commented

Version 5.x-dev means that this will be fixed in the master branch first; once fixed, it will become 'patch to be ported' on version 4.x-dev.

greg.1.anderson’s picture

greg.1.anderson commented
Issue tags: +Release blocker

Should fix for drush-5.

firebus’s picture

firebus commented

the documentation also states that

* In case of conflicting options, command-specific options in targets
* (source and destination) take precedence over command-specific options
* in the bootstrapped site, and command-specific options in a destination
* alias will take precedence over those in a source alias.

this also does not seem to be the case - command-specific options in a source take precedence over those in a destination alias in my experience

greg.1.anderson’s picture

greg.1.anderson commented

'source-command-specific' and 'target-command-specific' are now broken for sql-sync as well as core-rsync.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Fixed

Fixed source- and target-command-specific for sql-sync, implemented it for core-rsync, fixed ordering problem mentioned in #9, and also fixed #1418230: command-specific array in $aliases isn't doing anything.

Status: Fixed » Closed (fixed)

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

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Closed (fixed) » Patch (to be ported)

I suppose this won't be backported to 4.x then, as mentioned in #7?

greg.1.anderson’s picture

greg.1.anderson commented

This is a candidate for back-porting. I don't know if it will go in or not, but I should have set it patch to be ported instead of 'fixed'.

greg.1.anderson’s picture

greg.1.anderson commented
Assigned: greg.1.anderson » Unassigned
Priority: Major » Normal

With Drush-5 about to be released, this seems more like a nice-to-have than a must-have.

firebus’s picture

firebus commented

if the bug isn't going to be fixed, we should at the very least update the documentation. do we need a separate issue for the docs fix?

greg.1.anderson’s picture

greg.1.anderson commented

The next step would be for someone to submit a patch (code or docs)

msonnabaum’s picture

msonnabaum commented

If someone wants to post a 4.x patch I'll backport it, but since 5 is already out I won't be working on it.

moshe weitzman’s picture

moshe weitzman commented
Status: Patch (to be ported) » Fixed
Issue tags: -Release blocker

Status: Fixed » Closed (fixed)

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