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

[Tom F. <to...@mu...>]

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

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?


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Neil Stewart [mailto:ne...@r0...]
> Sent: 18 May 2003 00:10
> To: gam...@li...
> Subject: Re: [GD-General] Re: asset & document management
> 
> 
> > Why aren't they storing the most recent file and then doing 
> the binary
> diffs
> > backwards? So they store the diff of how to get from the 
> newest file to
> the
> > next newest file. That way the newest file would be fast to 
> use, you can
> > save full files every time you branch etc. Might be slower 
> to get old
> > versions but that's mostly for backup/safety anyway.
> 
> Well, they aren't storing any binary diffs at the moment, never mind
> backwards. ;)
> 
> I get your point, but I don't think they were willing to compromise
> performance on _any_ revision of a file, including the most 
> common usage of
> getting the latest version.
> 
> 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, 
> specifically as
> a bug-finding tool, i.e. you can roll back to a version where 
> a nasty bug
> does not exist and then roll forward to see what broke. This 
> would not be
> possible if they only optimised for the latest version of a 
> file, so they
> chose not to store binary diffs at all.
> 
> What I was suggesting was a halfway-house, where you could 
> tradeoff overall
> performance (on all files) against disk usage.
> 
> - Neil.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is 
> painful, 
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>