Re: [jgit-dev] JGit backup & synchronization

[epeters1111@xxxxxxxxx]

Wow, thanks for the quick answers.  One follow-up and a couple of comments inline.

> Another way is to store the repository on a filesystem that supports
> snapshots. If you snapshot the POSIX filesystem, the repository will
> be consistent as of that snapshot, and then you can backup the
> snapshot. E.g. btfs on Linux or ZFS on Solaris/FreeBSD. JGit (and
> normal Git) always perform updates in a safe ordered way to support
> this sort of approach.
> 
> It depends on how much data you are talking about. bundle/clone will
> produce a complete copy of the repository. For one repository done
> nightly, this isn't really a problem. For 1600 repositories that weigh
> in over 200G total, it is. Its that latter case where snapshotting
> filesystems can be useful with Git.

We have a SAN and can do snapshots, so we might look at that.  But our total data volume is going to be pretty orders of magnitude smaller than that, so it sounds like the other options would work fine, too.

> A bare repository is thread-safe.
> 
> I don't think we provide any assurances the working directory is
> thread-safe.


We had contemplated serializing writes so we didn't wind up stomping on the single working directory (again, very low data and request volume).  But we can work in the repo, too.  Again, sounds like we have multiple good options here.

> Yes, this is explicitly supported to permit end-users to use JGit from
> within an embedded application (e.g. Eclipse IDE) and still use
> git-core on the command line.
> 
>>  I'm thinking of two scenarios: (a) a user using command-line git at the same time our app is using JGit, and/or
> 
> Yes, like I just said this was an explicit design goal with JGit.
> 
>> (b) two app processes with a shared disk.
> 
> Also works.

This sounds like a difficult design goal to pull off; I'm really impressed.  (I would imagine this has the same caveat as above, about those multiple processes not clobbering the working directory?)

Thanks again for the help!

Regards,
Ed