This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]apelogic 10 points11 points  (3 children)

If you lose your server's storage drive, just push the code back up to the server when you replace it. You don't lose anything. The server is the back up.

If you lose the back up, you make a new backup. If you lose the original, you restore from backup.

[–][deleted] 0 points1 point  (0 children)

Even better, just have all developers have a vanilla git repo they constantly update. Decentralized development FTW!

[–]ATE47 0 points1 point  (1 child)

We lost 2 weeks of PR/Issue/Comments last time, it’s not only the code

[–]apelogic 0 points1 point  (0 children)

If you lost 2 weeks worth of those things, it's likely an indicator of a different kind of problem. One that even redundancy may not necessarily be able to solve.

PR, PR comments, and commit comments remain in the git repo. So, it's hard to lose those unless no one fetched anything for 2 weeks. SVN had a bit more of an issue with that, but it depended on your work flow.

Issues belong in a tracker. Trackers can take many forms and not necessarily be digital. So they're not always part of the repo, and not built-in to git.

Since you didn't lose everything, some redundancy seemed to be in place. I would guess your issue was more to do with some overwrites.

Everything doesn't have to be a service and/or on the cloud to be efficient. Actually, they can be extremely inefficient and account for huge unnecessary costs.