On Monday 27 March 2006 10:29, Paul de Vrieze wrote: > On Monday 27 March 2006 07:43, Ryan Phillips wrote: > > In actuality, Subversion does 98% of the commit in an initial > > transaction, and the blocking only occurs in the last 2% with the FSFS > > filesystem. It really isn't an issue and shouldn't prevent us from > > adopting it. > > Indeed, subversion first uploads the stuff, only then creates a new > revision. In any case one does not want multiple commits at the same time > in any case. For full portage the problems are more likely to be with svn > update. One can expect there will be a lot more updates than commits. As > the commits done are fairly small, those should not be an issue. Updates > work on the whole tree however. Initial checkouts are worse, because they > require the head to be reassembled (IIRC). Head checkout could be cached > though (but I don't think that's done currently).
This thread [1] from subversion-users asked about update/checkout performance. The svn people answered that performance usually isn't constrained by reassembly time. Moreover, the older BDB repo format stores the complete latest revision, and checkouts aren't significantly faster than from FSFS. (Of course, if SVN working copies didn't contain two complete copies of the stored data plus some fat metadata, then reassembly time would likely affect checkout time.) [2] explains the SVN skip-deltas storage method. Disclaimer, I haven't run any huge-repo benchmarks myself, just pointing to possibly relevant data. [1] http://svn.haxx.se/users/archive-2005-04/0518.shtml [2] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpu7JXGFbMyT.pgp
Description: PGP signature
