Roland Besserer wrote:
> Sorry about mangling the name - honest typo :-)
>
> Almost everything boils down to tradeoffs - we all have to make them in
> our designs or implementations. I can certainly see the reason for
> efficieny in the implementation of svn and the way data is stored and
> managed. I do not think the efficency argument is nearly as strong
> for a dump utility and dump file format which is, by implication, used
> sporadically. Not being part of the frequent operations performed as
> part of running svn on a daily basis, efficiency concerns should not
> supercede what I would call 'easy of use' - the ability to easily
> process the dump file with the widest variety of tools. I simply fail
> understand why one would want to place any arbitrary restrictions
> or limitations on the dumpf file format - particularly on that is
> announced as human readable. In my opinion the dump file
> format should be 7-bit ASCII (back to uuencode and the like :-)
I just wanted to point out that the assumption that 'svnadmin dump' is
run 'sporadically' isn't necessarily true. There are a number of folks
performing incremental dumps with every commit as part of having a
complete backup/recovery strategy. 'svnadmin dump' is run hundreds of
times per day in our setup.
It may have been intended originally for repository migration, but has
found other uses since then. :-)
> Anyway, not much point in rambling on about this. I can always write
> my own dump routine :-) ... but I think I can live with what we've got.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 5 04:24:53 2005