using git to version large files w/o checking them in

Joey Hess joey at kitenet.net
Thu Sep 30 16:26:08 CEST 2010


hessiess at hessiess.com wrote:
> The reason for choosing subversion in this case is due to the fact that it
> *DOES NOT* store the history client side, if it did, I wouldn't even be
> able to check out due to a lack of space.

But it does still store a useless copy of each file under .svn. Unless
you've found a new svn WC implementation that avoids that wart.

> In my opinion, what is needed is a system that stores all history server
> side, does not store two copies of the data locally and has the option to
> manage files without versioning them.

I need something beyond that; I need it to be distributed as well (not
always around a large file server), and I need the ability to have
asymetric clones that hold different subsets of the files, that change
on request.

> Unison works well in limited circumstances, but its slow and fails if you
> are syncing more than two computers. One solution is to use git with the
> remote mount/ --shared hack, but it would be better if it could do this
> natively.

Yeah, unison doesn't work for me due to everything you said -- for files
that unison can handle reasonably, I find just checking them into git with
--shared on low-space clones, while painful, is less painful than unison.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20100930/5488f46e/attachment.pgp>


More information about the vcs-home mailing list