Should I use GIT for a corporate file respository?

Question

We have a number of remote workers around the world that need to share the same files (including adding to and editing).

We have used SVN in the past with great results.

One of the biggest SVN repos we had was 17GB. The size was never the problem. We had all sorts of stuff in there, mainly binary files.

However, the drawback was that SVN stores a hidden folder in each folder is not too user friendly. (Esp when users copy and paste folders).

Git seems to solve this. The question is should I use Git, stick with SVN or is there some other open source tool that I've not come across yet?

There are many DVCS solutions that may meet your needs. If you like SVN, but dislike the .svn directories, have you explored SVN 1.7 where they moved it to a single .svn directory in the root? — AlG, Oct 27 '11 at 19:00
@Josh. No we didn't. I'm not sure now what version of SVN we had on the server. But it worked. We mainly used it for marketing collateral creation and review between marketing teams and review teams. — Blake K Peterson, Oct 27 '11 at 22:40
@AI. WOW ... have to look into 1.7 one .svn folder would solve our problem :) — Blake K Peterson, Oct 27 '11 at 22:41

score 1 · Accepted Answer · answered Oct 27 '11 at 19:00

If the main drawback you are worried about is the many .svn hidden folders, this is no longer the case as of v1.7.

See Working Copy Metadata Storage Improvements

A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every directory in the working copy, Subversion 1.7 working copies have just one .svn directory—in the root of the working copy. This directory includes (among other things) an SQLite-backed database which contains all of the metadata Subversion needs for that working copy.

Thanks ! - back to SVN I guess :) – Blake K Peterson Oct 27 '11 at 22:41 — Blake K Peterson, Oct 27 '11 at 22:41

score 1 · Answer 2 · answered Oct 27 '11 at 20:32

You're over thinking things here. You probably don't want a source control solution. If your workers are confused by the .svn files, they'll be confused with Git.

A possible solution is Dropbox. Dropbox places a folder called Dropbox either under your $HOME directory on Linux, Unix, and Mac, or under your My Documents folder on Windows. Any file put there will be synchronized to the Dropbox server.

If you go to another computer, and share the same Dropbox account, all files will eb there too. Dropbox works on Linux, Windows, and Macs.

If you all have Dropbox accounts, you can create shared folders between those accounts. You can share a folder between multiple people that way. Dropbox has some versioning mechanisms. You can get back previous copies of a file, so if you don't like a change, you can revert it. You can even get back deleted versions.

Dropbox is free for 2GB of data, and you can get more space if you are willing to pay. I use Dropbox for this type of situation, and the 2Gb account is usually good enough.

There are other similar services like SugarSync, but I like Dropbox's absolute simplicity. It works out great for non-technical users.

David Pogue just had a write up just a few weeks ago.

I'm not connected with Dropbox in any way except as a user who has found that it has greatly simplified my work.

Here's a list of Dropbox Alternatives. I can't vouch for any of them, but they're probably worth a look.

Thanks - I have known about dropbox for sometime, bit not keen on paying when there are probably better open source solutions out there. I've not heard about SugarSync.. I will def look into that. :) — Blake K Peterson, Oct 27 '11 at 22:38

score 0 · Answer 3 · answered Oct 27 '11 at 19:00

0

Git does keep an internal .git directory in the topmost directory from your repository.

The main advantage I find in Git is that all the history is available locally, and for laptops that make a huge difference.

answered Oct 27 '11 at 19:00

Basile Starynkevitch

223,805
18
296
547

Yeah that was the main pull from svn. – Blake K Peterson Oct 27 '11 at 22:39

score 0 · Answer 4 · edited May 23 '17 at 10:34

0

17GB would be very large for a git repository, ¹ and you would need to take care setting config options to make the experience bearable.

The use case of versioning lots of large binary files is one of the few areas where I think it's reasonable to still use Subversion instead of git or Mercurial.

^{1 _{I do use one git repository that is hundreds of gigabytes in size (for backup purposes), but this is something of an obscure sport.}}

edited May 23 '17 at 10:34

Community

1
1

answered Oct 27 '11 at 19:12

Mark Longair

446,582
72
411
327

Thanks! Yes - Looks like that's the solution SVN 1.7. – Blake K Peterson Oct 27 '11 at 22:44

score 0 · Answer 5 · answered Oct 27 '11 at 19:24

0

If you use VCS only as shared file storage, this is overkill for such task. And most of SCMs handle binary files rather poor. You have giant overhead in size for storing mostly useless (for binaries especially) revision history

Resume - I can't see reasons to move to Git (and even use SVN - ordinary WebDAV location may be enough)

answered Oct 27 '11 at 19:24

Lazy Badger

94,711
9
78
110

Yeah looks to be the case :) Thanks for your comments. I originally thought about overkill at first. However we used one directory with live production files, and then used a cron to checkout these to a folder on our website. This was a great solution to keep website images and collateral up to date. – Blake K Peterson Oct 27 '11 at 22:43
FAM-module for monitoring changes in FS and oneliner "copy src dst" may work this way and almost in real-time – Lazy Badger Oct 28 '11 at 00:06

Should I use GIT for a corporate file respository?

5 Answers5