Feature Request: Specify Backups Directory
Opened this issue · 7 comments
We encoutered an issue where an automated script was scanning a directory to delete files and it followed symbolic links and delete local development packages as well.
It would be really nice if I could specify the live-archive backup directory instead of it assuming @rootDir + '/.live-archive'.
ie, I would like to have my backups located at $HOME/.live-archive and my project's backup directory might end up as $HOME/.live-archive/e673524da10f526b1c26f6e5612303bc236b7d367cf2a8e0081cc2b50ce199b5/ (sha256 hashing the @rootDir)
I will consider this when I get a chance. For now I'll give the standard
answer "Pull requests are welcome." (grin)
On Thu, Jan 7, 2016 at 2:55 PM, Bradyn Poulsen notifications@github.com
wrote:
We encoutered an issue where an automated script was scanning a directory
to delete files and it followed symbolic links and delete local development
packages as well.It would be really nice if I could specify the live-archive backup
directory instead of it assuming @RootDir + '/.live-archive'.ie, I would like to have my backups located at $HOME/.live-archive and my
project's backup directory might end up as
$HOME/.live-archive/e673524da10f526b1c26f6e5612303bc236b7d367cf2a8e0081cc2b50ce199b5/
(sha256 hashing the @RootDir)—
Reply to this email directly or view it on GitHub
#16.
Great package @mark-hahn!
+1 on this feature request.
It is easy for developers to forget to create a .live-archive directory for every project. Additionally, often files don't have an associated project, but would still benefit from being able to use this live archive package.
Being able to specify the backup directory once for all projects and files as $HOME/.live-archive would be very welcomed. Most - if not all - other similar backup packages for Atom all share a single, backup directory.
I personally like being able to back up the history of a project with the project. Also there is the problem of keeping track of a project when it is moved. But I understand the reasons for this request.
forget to create a .live-archive directory for every project.
There is a warning in the status bar when there is no archive and you only need to click on that to have a directory set up.
Most - if not all - other similar backup packages for Atom all share a single, backup directory.
The most used one, git, doesn't. Do you think .git should be centralized?
I'm sorry that I argue. I have no problem having that option. It is just way down on my priority list, as is every issue that don't personally want.
I personally like being able to back up the history of a project with the project.
The issue we had when I requested the feature was a developer hadn't done any backups/pushes of his project yet. He executed one of his utility scripts that he wrote. It was to delete a directory and its contents, except he forgot to ensure he did not follow symbolic links during is recursive delete (in addition to other files he had to check for). All in all, the entire project folder was delete along with his .live-archive directory within the project.
I agree that it's nice to, by default, have the .live-archive inside the project, but it would be very nice to specify a centralized directory separate from your project files.
The 2nd most used backup mechanism we use is Time Machine which uses a separate hard drive/network drive altogether (which you configure which to use in its settings).
Surely there was a backup of the deleted project. Live-archive was not
designed to be a primary backup. It lacks some backup features.
That accident was pretty specific. I could see where other accidents could
destroy the centralized data. For that matter not having it centralized
could be considered an advantage because of the reduced chance of losing
data for all projects.
On Sat, Mar 12, 2016 at 1:51 PM, Bradyn Poulsen notifications@github.com
wrote:
I personally like being able to back up the history of a project with the
project.The issue we had when I requested the feature was a developer hadn't done
any backups/pushes of his project yet. He executed one of his utility
scripts that he wrote. It was to delete a directory and its contents,
except he forgot to ensure he did not follow symbolic links during is
recursive delete (in addition to other files he had to check for). All in
all, the entire project folder was delete along with his .live-archive
directory within the project.I agree that it's nice to, by default, have the .live-archive inside the
project, but it would be very nice to specify a centralized directory
separate from your project files.The 2nd most used backup mechanism we use is Time Machine which uses a
separate hard drive/network drive altogether.—
Reply to this email directly or view it on GitHub
#16 (comment)
.
Regardless of which way you prefer, it's just as easy to throw out that it
can be deleted
On Mar 12, 2016 15:03, "mark-hahn" notifications@github.com wrote:
Surely there was a backup of the deleted project. Live-archive was not
designed to be a primary backup. It lacks some backup features.That accident was pretty specific. I could see where other accidents could
destroy the centralized data. For that matter not having it centralized
could be considered an advantage because of the reduced chance of losing
data for all projects.On Sat, Mar 12, 2016 at 1:51 PM, Bradyn Poulsen notifications@github.com
wrote:I personally like being able to back up the history of a project with the
project.The issue we had when I requested the feature was a developer hadn't done
any backups/pushes of his project yet. He executed one of his utility
scripts that he wrote. It was to delete a directory and its contents,
except he forgot to ensure he did not follow symbolic links during is
recursive delete (in addition to other files he had to check for). All in
all, the entire project folder was delete along with his .live-archive
directory within the project.I agree that it's nice to, by default, have the .live-archive inside the
project, but it would be very nice to specify a centralized directory
separate from your project files.The 2nd most used backup mechanism we use is Time Machine which uses a
separate hard drive/network drive altogether.—
Reply to this email directly or view it on GitHub
<
#16 (comment).
—
Reply to this email directly or view it on GitHub
#16 (comment)
.
We're not talking about using it as a primary backup, but if he would've
been able to use it as a short term backup and revert even just 2 minutes
where the project was, he'd be golden.
I'll just let him know not to expect a backup directory setting for a long
time since it's being deemed useless
On Mar 12, 2016 15:03, "mark-hahn" notifications@github.com wrote:
Surely there was a backup of the deleted project. Live-archive was not
designed to be a primary backup. It lacks some backup features.That accident was pretty specific. I could see where other accidents could
destroy the centralized data. For that matter not having it centralized
could be considered an advantage because of the reduced chance of losing
data for all projects.On Sat, Mar 12, 2016 at 1:51 PM, Bradyn Poulsen notifications@github.com
wrote:I personally like being able to back up the history of a project with the
project.The issue we had when I requested the feature was a developer hadn't done
any backups/pushes of his project yet. He executed one of his utility
scripts that he wrote. It was to delete a directory and its contents,
except he forgot to ensure he did not follow symbolic links during is
recursive delete (in addition to other files he had to check for). All in
all, the entire project folder was delete along with his .live-archive
directory within the project.I agree that it's nice to, by default, have the .live-archive inside the
project, but it would be very nice to specify a centralized directory
separate from your project files.The 2nd most used backup mechanism we use is Time Machine which uses a
separate hard drive/network drive altogether.—
Reply to this email directly or view it on GitHub
<
#16 (comment).
—
Reply to this email directly or view it on GitHub
#16 (comment)
.