> [18:18] <ben_> the *output* of vdelta is svndiff data
I'd like to make this a little more precise, since I'm not sure Sander
took the right thing idea of the conversation:
The output of vdelta is a series of block-copy operations, divided up
into windows to allow for streamy application. svndiff is a way of
representing a series of block-copy operations as bytes. Obviously,
you could replace either side of the equation with something else.
> [18:20] <striker> Hmm, post 1.0, would it be worthwhile
> investigating an rsync like diff (mostly usefull when there isn't a
> pristine version hidden in the wc)?
I'm of this opinion that this is not worthwhile. Currently, there's
no operation in Subversion I know of which could benefit from an
rsync-like diff. In a future Subversion which has an option to not
require base texts, one could imagine using something rsync-like to
speed up commits, but I think it would take a lot of work on the
network protocol and I doubt anyone would care. In most environments
you either have enough disk space for base texts or enough network
bandwidth to transmit plaintexts for files you need to diff or
commit.
> [18:23] <ben_> disk is just *so* cheap, that it's not worth the
> trouble
Disk is cheap. Backed-up, network accessible disk is not especially
cheap. I manage a roughly 1GB source tree at MIT, with the repository
and all the working copies in AFS, which (1) is rather slow (so
writing two copies of each file means taking extra time) and (2) is
easier to manage if you don't create huge volumes of data. You could
argue that using AFS is a mistake, but on the scale of a system like
ours, NFS is totally unmanageable; you can't do important things like
move data from one server to another without creating a serious
user-visible event.
> [18:25] <ben_> I guess we also assume that most programmers have
> their own machines...
Sure, I have maybe a dozen of my own machines between home and work;
it's important to be able to do work on any of them. Thus, I wind up
using filespace which isn't as cheap as raw disk.
We've also had bad experiences with developers keeping working
directories on local disk. One co-worker lost three months of effort
when his workstation's hard disk crashed. His project was never
completed.
I hope this helps explain the kind of situation where doubling the
size of a working copy is not feasible. It's unlikely that we will
use Subversion as long as it imposes the base-text penalty on working
copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006