4 ms·

wouldn't package.json be enough?

codetrotter 4y ago
They probably have a folder that auto syncs with Google Drive https://support.google.com/drive/answer/10838124?hl=en https://support.google.com/drive/answer/10838124?hl=en Same way that Dropbox works So they are not manually choosing what to sync, they just put all of the work and other files they want to automatically sync inside of that folder. This ends up including things like node modules and things like that
- NoZebra120vClip 4y ago
  I don't sync folders. I mount my accounts as network drives. As for corruption or overwriting files, I have rarely encountered issues, but Drive has file revision histories as well as a Trash can, so if you notice the problem and it's not spread over 5M files, you can roll back to last-known-good versions.
  - codetrotter 4y ago
    > I don't sync folders. I mount my accounts as network drives. Implementation-wise under the hood is it really much different? In my simplistic, probably overly naive idea it seems that a “network drive” built on top of Google Drive would still cache the files in memory, and improper shutdown or loss of network access could still leave your files in an inconsistent state. Probably they have a lot of advanced logic on top, that could roll back partial updates, or keep track of things so that the updates are not applied before sync is complete. But anyways from this point of view sync vs network mounted drive feels like sync is a kind of network mounted drive that flushes to local disk in addition to working with the remote. One of these days I want to build such things from scratch myself so that I can experience first-hand the horrors that lie underneath sync / network disk service setups modelled on my idea of Dropbox / Google Drive etc
- gumby 4y ago
  > a folder that auto syncs with Google Drive...Same way that Dropbox works I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless. It frequently crashes mysteriously, and even when running it doesn’t sync reliably. It feels like nobody is working on the software, and after all the layoffs that could well be true. Say what you want about Dropbox, but I’ve never had a problem with it.
  - kcartlidge 4y ago
    > I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless True. I used Dropbox for many years without issue and moved because of the cost and the issue a few years back with not allowing it on certain Linux file systems. Went to Google Drive and performance was shocking in comparison. At the time (don't know about now) it also felt like they had a deliberate policy to avoid showing cumulative file/folder sizes, meaning it was easier to pay for more storage than to find out what took the space and clean it up. Since then I've spent a few years using PCloud, which was almost as fast as DropBox and more reliable at syncing than Google. Then I lost the ability to connect the client on a Mac for a couple of days, had a deeper look, and noticed a few files had had silent collisions between changes on Mac and Windows (not at the same time) leaving multiple versions (names suffixed with the machine they came from). So I left there and went to OneDrive. To be honest I've found it okay other than one issue on a Mac where if I delete a file for some reason then when it vanishes to the recycle bin it reappears in the OneDrive root on the laptop. delete-immediately gets around that. I'm now at the point where I use OneDrive for convenience/reliability but despite the cost have been considering a return to DropBox as cloud syncing seems to be impossible for anyone else to do properly. Is it still as reliable as it used to be?
    - gumby 4y ago
      I tried OneDrive for a while but it wouldn’t sync certain files due to characters in their names. The error message wouldn’t tell me which. But much better than google which just silently fails.
csomar 4y ago
More like your lock file. That being said, if I am paying for storage, that's because I want an exact replica to what I have on disk.
johannes1234321 4y ago
Not saying that the approach taken via G Drive is smart, but to your question: For a full backup of your application just storing package.json/package-lock.json is not enough. In case of things going south this might leave you in an unrecoverable state - imagine a package is removed for whatever reason from npm or npm becomes unreachable. Now in your risk assessment the question of course is how likely it is that you lose the copy alone your dev system, CI system and productive version at the same time that npm loses it, but the first three happening isn't as unlikely as it seems: You work on a major refactoring and while deploying you run into a major problem and want to roll back, then artifacts from the old version might be gone. Of course there are ways to prevent that. But that's the risk assessment and prevention you have to make. A full backup including node_modules is one way of dealing with that.

They probably have a folder that auto syncs with Google Drive https://support.google.com/drive/answer/10838124?hl=en https://support.google.com/drive/answer/10838124?hl=en Same way that Dropbox works So they are not manually choosing what to sync, they just put all of the work and other files they want to automatically sync inside of that folder. This ends up including things like node modules and things like that

NoZebra120vClip 4y ago
I don't sync folders. I mount my accounts as network drives. As for corruption or overwriting files, I have rarely encountered issues, but Drive has file revision histories as well as a Trash can, so if you notice the problem and it's not spread over 5M files, you can roll back to last-known-good versions.
- codetrotter 4y ago
  > I don't sync folders. I mount my accounts as network drives. Implementation-wise under the hood is it really much different? In my simplistic, probably overly naive idea it seems that a “network drive” built on top of Google Drive would still cache the files in memory, and improper shutdown or loss of network access could still leave your files in an inconsistent state. Probably they have a lot of advanced logic on top, that could roll back partial updates, or keep track of things so that the updates are not applied before sync is complete. But anyways from this point of view sync vs network mounted drive feels like sync is a kind of network mounted drive that flushes to local disk in addition to working with the remote. One of these days I want to build such things from scratch myself so that I can experience first-hand the horrors that lie underneath sync / network disk service setups modelled on my idea of Dropbox / Google Drive etc
gumby 4y ago
> a folder that auto syncs with Google Drive...Same way that Dropbox works I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless. It frequently crashes mysteriously, and even when running it doesn’t sync reliably. It feels like nobody is working on the software, and after all the layoffs that could well be true. Say what you want about Dropbox, but I’ve never had a problem with it.
- kcartlidge 4y ago
  > I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless True. I used Dropbox for many years without issue and moved because of the cost and the issue a few years back with not allowing it on certain Linux file systems. Went to Google Drive and performance was shocking in comparison. At the time (don't know about now) it also felt like they had a deliberate policy to avoid showing cumulative file/folder sizes, meaning it was easier to pay for more storage than to find out what took the space and clean it up. Since then I've spent a few years using PCloud, which was almost as fast as DropBox and more reliable at syncing than Google. Then I lost the ability to connect the client on a Mac for a couple of days, had a deeper look, and noticed a few files had had silent collisions between changes on Mac and Windows (not at the same time) leaving multiple versions (names suffixed with the machine they came from). So I left there and went to OneDrive. To be honest I've found it okay other than one issue on a Mac where if I delete a file for some reason then when it vanishes to the recycle bin it reappears in the OneDrive root on the laptop. delete-immediately gets around that. I'm now at the point where I use OneDrive for convenience/reliability but despite the cost have been considering a return to DropBox as cloud syncing seems to be impossible for anyone else to do properly. Is it still as reliable as it used to be?
  - gumby 4y ago
    I tried OneDrive for a while but it wouldn’t sync certain files due to characters in their names. The error message wouldn’t tell me which. But much better than google which just silently fails.

csomar 4y ago

More like your lock file. That being said, if I am paying for storage, that's because I want an exact replica to what I have on disk.

johannes1234321 4y ago

Not saying that the approach taken via G Drive is smart, but to your question: For a full backup of your application just storing package.json/package-lock.json is not enough. In case of things going south this might leave you in an unrecoverable state - imagine a package is removed for whatever reason from npm or npm becomes unreachable. Now in your risk assessment the question of course is how likely it is that you lose the copy alone your dev system, CI system and productive version at the same time that npm loses it, but the first three happening isn't as unlikely as it seems: You work on a major refactoring and while deploying you run into a major problem and want to roll back, then artifacts from the old version might be gone. Of course there are ways to prevent that. But that's the risk assessment and prevention you have to make. A full backup including node_modules is one way of dealing with that.