Bug 824577

+++ This bug was initially created as a clone of Bug #802537 +++

We need to make the initial deploy to a destination consistent
with the update/redeploy to the same destination.

Today, the behavior is inconsistent. When you deploy the bundle for the first time to
a destination and manageRootDir=false, we do not touch any of the files or
subdirectories in the destination directory even when the bundle has the same
subdirectory but on redeploy we do cleanup those files not in the bundle.

To illustrate:

bundle.zip:
   subdir/foo.txt


dest-dir:
   subdir/bar.txt


On initial deploy I end up with:

dest-dir:
   subdir/bar.txt
   subdir/foo.txt


But on update or redeploy I end up with:

dest-dir:
   subdir/foo.txt

Bug #801926 is related - that relates to what we want the behavior to actually be in this case.

But for this issue, we want to make the behavior consistent one way or the other. I will attempt to fix this so the "update" behavior is how the initial deploy should behave. In other words, after the initial deploy, we should have:

dest-dir:
   subdir/foo.txt

because this was the original intent with the bundle system. In other words, the bundle itself defines EVERYTHING under the deployment main directory (so whatever the bundle says should be in subdir should be in subdir - no less and NO MORE). The manageRootDir=false means "do not manage the ROOT directory (only)" but all subdirectories will be fully managed by the bundle (which is why update acts as it does and why I want the initial deploy to work like the update does).

See Bug #801926 in regards to whether this SHOULD be the way it works in the future - if not, we will need to keep in mind backwards compat issues, documentation issues and the amount of time it would take to change the behavior of manageRootDir=false. I suspect we will need to add something like "manageSubDirs=false" to do what it currently the initial deploy behavior (that is, leave any existing files alone in all subdirectories). But that's just a guess - again, bug #801926 will track that.