>
>> one corrupt bit, and you risk loosing the entire held state. 
>
>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.

Not at all. If you loose the RCS file for bin/ls/RCS/ls.c,v .. you have
lost one .c source.

If you loose the fsfs/db/<xx> file, you've lost the entire repos for that
file. All of it.

No?

>
>> 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...

You are explicitly told by SVN people in their online docs to do this
between major variants of SVN because of non-backwards compat change risks
in the .DB format. Has that now changed with FSFS? Is it now honouring the
prior formats to obviate that path?

svn-hot-copy is neat of course.

>
>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.

Um.. these packages  (and they are packages under /usr/pkgsrc/...) are
*TINY* by comparison. NetBSD is carring far far more revision/variant
information. 

 
>
>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.

I think the other mails about problems during import of NetBSD sources when
tested stand. My personal experience is limited to a 2-3 year old cvs repos
and the problems it had with import, none of which were insurmountable but
its not entirely 'trivial'.

I also tried to use a VSS import tool but I can understand why that would
be error prone!

-George

>
>
>Alec
>


-- 
George Michaelson       |  APNIC                 
Email: ggm@apnic.net    |  PO Box 2131 Milton    
Phone: +61 7 3858 3150  |  QLD 4064 Australia    
  Fax: +61 7 3858 3199  |  http://www.apnic.net