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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Reply via email to