RE: [GD-General] Re: asset & document management

[Stefan B. <ste...@te...>]

> > One of the things they seem to pride themselves in is
> > Perforce's ability to
> > reliably roll-back to any changelist or label very quickly,
>=20
> I'd think the time required to grab huge files from a server is =
comparable
> to the time required to get the much smaller diffs and apply them to =
the
> existing file. We've found that even complex stuff like LZ-like
> compression makes disk accesses faster, not slower, because it's so =
fast
> to decompress and still gives good space savings. So applying a diff =
is a
> doddle, surely?

   Hmm... I don't think I would really like to use a revision control =
system
where rollback took place locally, using local data. The diffs are =
always
applied on the server and the resulting file is sent to the client.
Therefore grabbing a big "key" file (i.e. a standalone copy much like a
key-frame in video files) and applying a set of deltas would have to be
performed on the server and then sent to the client. Unless you can come =
up
with a very clever on-the-fly delta application algorithm, this could
consume a fair amount of server resources, which is something P4 tries =
very
hard not to do (and that's why it scales to a very large number of users
without requiring a hefty server).

   Grabbing the latest version is the most common action anyway so this
might not be such a big issue in practice but in the presence of =
branches
there's not always just one "latest" version which complicates things ;)

   I believe the Subversion team originally stated that binaries would =
be
stored using (xdelta? rsync?) deltas but that's not been implemented yet =
so
I guess it's not as easy as they anticipated.

Cheers,
Stef!
--
Stefan Boberg, R&D Manager - Team17 Software Ltd.
bo...@te...