hessi...@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
Description: Digital signature
_______________________________________________ vcs-home mailing list email@example.com http://lists.madduck.net/listinfo/vcs-home