Selective propagation of deletions, + rsync scope

[Brian K. White]

On 6/2/2011 6:03 PM, Matt McCutchen wrote:
> On Thu, 2011-06-02 at 17:43 -0400, Brian K. White wrote:
>> Perhaps the server side could specify all the deleted files and
>> directories as being excluded before they are actually removed from the
>> server. Then the client could use --delete but not --delete-excluded and
>> get essentially the optimal behavior.
>
> Yes, that's what I meant.
>
>> Almost all of rsync's features could be argued either way,
>
> Indeed.  Of all the software packages I'm familiar with, rsync seems to
> attract this kind of debate the most often, for precisely the reasons
> you mention.

Heh. Well bash and ksh just built-in a good chunk of an OS. And zsh and 
emacs built-in just as much PLUS a plugin architecture that adds 
everything else imaginable.

> In the first place, I'm telling you not to expect Wayne to change his
> decision.  I'm not sure I would defend it per se, but I have gained a
> great deal of respect for his approach of being selective about features
> and working to make the ones that are there as robust as possible.

Fair enough.

Similarly, I don't necessarily need the OP's 
suspend-gracefully-with-informative-server-response feature at the 
moment. I'm only saying, that I think it does align with existing design 
and development thus far.

Many existing features clearly and explicitly exist to allow rsync to be 
used as a standalone daemon, and in public settings, and clearly always 
strives to be as robust as possible both in itself as well as provide 
for as robust as possible usage by the user/script/app.

And, unless someone discovers a trick I haven't spotted yet, as far as I 
can tell the lack of this feature does prevent or at least make less 
robust that basic intended usage in some situations.

I haven't finished playing with the exclude file idea so it may be that 
the difference in behavior of an excluded directory vs a missing 
directory vs down service may be detectable from the client and serve as 
a good enough replacement for an explicit status code response from the 
server.

-- 
bkw