using git to version large files w/o checking them in
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
> 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
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
Size: 828 bytes
Desc: Digital signature
More information about the vcs-home