--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

George Michaelson on 2005-02-06 09:45:32 +1000:

> Server side is ... strange. the files are held either as berkeley
> .DB file (singular, entire repositary) or as split files to provide
> faster service, but not in any 1:1 relationship to the files of the
> 'project' in question.

To clarify: there are two repository backends, BDB and FSFS.  FSFS
does not provide a "1:1 replations to the files of the project", but
rather each file represents a particular revision.

This is nifty because an administrator can symlink older revisions to
a different disk (or from a RAM disk to a real disk, to address a
perceived shortcoming of svn by another poster). =20

I've administered repositories using both backends and recommend the
FSFS one; you can read more about the pros and cons at
http://svn.collab.net/repos/svn/trunk/notes/fsfs.  The one major con
=66rom the perspective of using it to replace anoncvs in NetBSD is that
FSFS incurrs more overhead checking out HEAD than BDB.

> one corrupt bit, and you risk loosing the entire held state.=20

Only for BDB will one corrupt screw the repository, but that's sort of
like saying that one corrupt bit and you risk losing an entire RCS
file.  It's a non-point.

> It has a textual dump format but for a large project, with many
> years history and branches, this would be quite costly to hold
> online.

The dump format is the most cumbersome way to transmit a repository.
That would be like doing database replication by dumping tables,
copying them, and reinsterting them.  It works, but, well...

The most visible use of the replication tools is svk, which turns
subversion into a darcs/arch-style distributed RCS tool through use of
perl modules.

> In other respects its very nice, but you have to wonder about the
> back-end format until its really well proven in use.

Check out subversion's propaganda page.  Also note that samba and
apache projects have use subversion for over a year (I believe) -
that's pretty proven in my book.

> the server is otherwise nice. Its WEBDAV, it understands symlinks,
> dirname changes, dir removal. Its possible to tie into it WIKI based
> tracking systems, and thus do release engineering against accepted
> bugs/issues in a tracker.

The server isn't WebDAV per se; there is an Apache 2 module which
allows read/write using WebDAV.  There's also a server which can run
over ssh.

TRAC is a pretty nifty tool - as you said, it rolls a wiki and a
problem reporting system and the repository into one nice package.=20

As someone else has said, the subversion server has more
overhead than the cvs server.

In terms of the client, the overhead is quite a bit more than cvs -
subversion stores a copy of the last revision in .svn/, so users would
need to double the space they allocate to the source tree.  That
feature is there to speed up common developer operations like diffs,
reverts, and checkins.

> cvs importing tools are still immature.

I don't think that statement is accurate, but I can't point to any
links to refute it.


Alec


--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFCBWZhAud/2YgchcQRAhjMAKDZ9jCoVOz45hpP9eNvRptlIn9WLgCgnUtt
VxjKsNEGrr+AKdeQzZM+Iyo=
=BOex
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--