0

I am using a piece of desktop software that does some fairly complex work over numerous files, and using it with the files opened from Dropbox has caused severe data loss problems in the past. (because of Dropbox syncs while the software is running) The files (some text, some binary) are critically important so I want to secure them from damage as much as possible, and I need to use the files from multiple computers and want the ability to go back in history in case they are corrupted, so using git seems to be a perfect fit for this. But I'm fairly new to git itself.

Note: Any given user will only be working on their own files, so there is no scenario in which multiple users would push to a single repo. Each user would have their own files tracked in their own repo in their own instance of Dropbox. The entire point is to have this capability unique to each user so their files are essentially backed up and version controlled via git and Dropbox.

After reading a bit (especially the top two answers here and this great discussion and this article on bare vs non-bare repos) it seems there are a few different approaches with a lot of pro and con discussion, and I'm wondering which approach below would be best in this specific single-user situation?

Basically the options I see are to use Dropbox as a single-user git "server" by having it host a bare repo that I clone locally each time, or to have no metaphorical server and just use Dropbox as a file server with a non-bare git repo that I copy (in full) from/to each time.

Option 1: Bare repo in Dropbox, script clones it to a local working directory: c:\dropbox\master.git is a bare repo, and the script does a git clone c:\dropbox\master.git c:\working, runs the software against the checked out files in c:\working, then does a git add and git commit and git push origin master and deletes c:\working and then its done.

Option 2: Non-bare repo in Dropbox, script copies it to a local working directory: After copying the entire c:\dropbox\master directory to c:\working it runs the software against the files in c:\working, then does a git add and git commit and then overwrites c:\dropbox\master with the contents of c:\working and deletes c:\working and its done.

The final powershell script will also shut down the Dropbox service before it does anything, and start it back up after it commits (option 1) or copies (option 2) back to the master in Dropbox. That part's easy actually and will guarantee Dropbox doesn't change any files while the local repo is being worked on. And since it will be a single-user process, I (or whomever) can wait a few minutes for Dropbox to finish syncing upon first boot.

Option 1 seems more "git-ish", but given the single-user scenario option 2 may be a bit simpler (only 1 repo to deal with instead of 2) but I'm not sure if there are any "gotchas" I'm missing here.

Thanks for any tips/ideas/etc.

Community
  • 1
  • 1
Dave
  • 1,057
  • 2
  • 12
  • 18

1 Answers1

0

Option 3: Normal (Non-bare) Git Repo Dropbox: Easier than options 1 and 2 because you don't have to worry about copying things to different places. Just use it like a normal local git repository, except it is automatically synced to the cloud.

I personally use option 3. Dropbox is designed to seamlessly sync your files to the cloud while they act like normal files on the computer you're using. There is pretty minimal risk doing it this way. Just make sure your changes are synced when you stop working. (Don't make changes on one computer while offline, then make changes on a separate computer before the first changes are synced.) If anything does get corrupted somehow, Dropbox has built-in rollback anyway.

None of the solutions mentioned are horrible - any would work fine. But I see no reason to make it as complicated as options 1 & 2.

mkasberg
  • 16,022
  • 3
  • 42
  • 46
  • Yes but that has the git repo in Dropbox doubling as the working folder right? If so that isn't viable as we can't have the software accessing files in Dropbox. Even with Dropbox disabled while the software was running. Once it was re-enabled we once experienced a sudden 3-way sync from 3 systems that ended up breaking the app. It's not Dropbox's fault per se, the app is just ridiculously fragile and doesn't deal with *any* tampering of its file structure, but that's what I have to deal with. – Dave Mar 31 '16 at 01:26
  • Perhaps the problem is Dropbox. Why don't you use a normal git repository, either hosted yourself or from one of the many popular git hosting services? – mkasberg Mar 31 '16 at 14:02