Centralized repository

I know that this has been mentioned before. So, I will only bring it up once (from me at least).

I have a project that is currently over 2gigs without .git and growing. It is a personal website that I use to provide/remind me of things that I used to remember when I was younger. When you put a GIT repostitory in it, you get almost 4gigs of space taken (and this amount is growing all the time). Then I keep it centralized, because I own several machines (OK, way too many, over 20 currently, dedicated to Folding@Home). So, it takes up a lot of disk space over all those machines.

Because it is so big, cloning no longer works. I can't remember the exact errors, but I gave up and now tar up a semi-current version and untar it on a new/re-installed machine. Then I do a "pull" to update it and that works when the clone doesn't. I should mention that I have only 2 windows machines, but run GIT on all the rest which are Linux and MacOSX machines.

Anyway, for this one repository, I would really like GIT to support the CVS/SVN central repository system. The rest of the time, I am quite happy with GIT's distributed system even though all of my repositories are really just for me.

Last, thanks for GIT. I really enjoy it and use it daily and have never had it fail on me (no matter what I did!)!

Bob White

On Sat, Feb 24, 2007 at 09:14:27PM -0500, bob wrote:

For a while I was running git with an 80-gig repository of media files. I found it useful to network mount the central git repo (I used SMB), and clone to the local machine using alternates (i.e., "git clone -s /net/mounted/git /local/git"). It should work as a normal git repo, except that all object accesses will transparently go over the network, which obviously slows things down a bit (but no slower than CVS!).

You should be able to pack at your size of repo (I obviously couldn't, but I was working with a few very large files, so the overhead wasn't too bad).

HTH, -Peff

On Sunday 2007, February 25, bob wrote:

In the case of subversion: you really /wouldn't/ want that model. Subversion keeps a local pristine copy in the .svn directory of every file. This makes local diffs and stats fast and not require network access, but also doubles the storage requirements of your working directory.

I've found that a packed git repository is often smaller than a full checkout of the project (it's almost scary actually - your entire project's history in less space than the project).

Andy

söndag 25 februari 2007 10:51 skrev Andy Parkins:

That doesn't apply to a repo full of (already compressed) binaries media files. You cannot pack them unless the binaries are so small that the wasted space at the end of the last disk block is a significant amount of the total used. You cannot diff them either, other than seeing that they are different.

Besides the 4 GB mentioned isn't much nowadays. If it is annoying to have the .git directory in the same filesystem tree you can place the .git directory somewhere else and drop a symbolic link in it's place.

Btw, is it possible to make a full repo shallow again, by pruning the "uninteresting" part of the history? That would make it possible to trim down the size of the local archive.

-- robin

hoi :)

On Sat, Feb 24, 2007 at 09:14:27PM -0500, bob wrote:

this is fixed in the master branch now.