Changes between Initial Version and Version 1 of Ticket #23724, comment 6


Ignore:
Timestamp:
Oct 29, 2014, 8:49:47 AM (10 years ago)
Author:
Prathik Rajendran M

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23724, comment 6

    initial v1  
    11Yup it's definitely a mistake but we could be mitigating the damage if Django prevented `--clear` from happening in this case, at times developers don't handle the deployment or there could be multiple developers, someone might have not read that warning, thus I think Django should at least warn that they are within the app's folder and that what is deleted can't be restored by collectstatic.
    22
    3 Is there a way in which we can prevent collectstatic from deleting the folder if it belongs to an app? That is if the STATIC_ROOT points to a folder within an app then it shouldn't be deleted or atleast user should be warned about the cost.
     3Is there a way in which we can prevent collectstatic from deleting the files if they don't belong to the app?
     4
     5Also if the STATIC_ROOT points to a folder within an app then it shouldn't be deleted or atleast user should be warned about the cost, that is they have to re-deploy to get the files back and if they don't have a repository then the files are lost forever.
    46
    57Also I think it would be better if --clear only deleted files that belongs to Django, this would allow multiple apps (non-django) to write into the STATIC_ROOT too. These were the reasons that led to the development of the `--overwrite` mode, which doesn't touch any other file apart from that which belongs to django.
Back to Top