Date: Mon, 6 Mar 2006 11:26:22 +0100 From: Ollivier Robert <roberto@keltia.freenix.fr> To: freebsd-arch@freebsd.org Subject: Re: Subversion? (Re: HEADS UP: Importing csup into base) Message-ID: <20060306102622.GB21025@tara.freenix.org> In-Reply-To: <200603051930.25957.peter@wemm.org> References: <20060304141957.14716.qmail@web32705.mail.mud.yahoo.com> <20060304152433.W61086@fledge.watson.org> <BA422F74-E7F9-4F53-9A88-B89E2255FF00@behanna.org> <200603051930.25957.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
According to Peter Wemm: > Like perforce, it is fully client/server, but it has some considerable > advantages over perforce: > > 1) It has fairly good detached operation modes. You can do logs, diffs, > reverts, etc while detached. It does this by keeping metadata and a > small number of revisions cached locally. In my opinion, it is not enough. You can't svn commit on a detached mode. You can't work as if you were connected, commit several csets, go back one and so on. That's too limiting. > 5) And this is the kicker.. most client metadata is kept on the client! > This is the very reason why we cannot use perforce for freebsd.org for > everybody. The number of checkouts is way too large. svn keeps most > of this on the client, so this scales easily with more clients. Including a full copy of all files and more metadata. The inode count for /usr/ports would be even worse than Mercurial (which is already big but we have *full* history and disconnected ops). And someone is working on a better way to store data in a Mercurial repo which will save us thousands of inodes at some CPU expense. First tests on this indicates at least a 50% saving on disk space for the .hg directory and far less inodes consummed. > The comments about svn's lack of branch merge memory make me a bit > nervous though. We've had brahcnes that have been incrementally merged > hundreds of times under perforce, and the lack of remembering which > revisions have and have not been merged would be sorely missed. Yes. > And my personal observation is that svn finally seems to be becoming the > defacto replacement for cvs, at last. It has picked up some very high > profile projects - gcc for one, asterisk, etc etc. I'm sure it will > improve at an even faster rate now. Xen is using Mercurial, OpenSolaris is evaluating it along other dVCS too. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin snuadh.freenix.org Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060306102622.GB21025>