The ideal here, of course, would be for versioning to store deltas. If a property changes, record the change in the property alone, etc. If the content is text and the content changes, store a diff, not a new copy (much like CVS). If the content is binary, then store a binary delta. There are open source Java projects available for performing binary deltas, such as http://sourceforge.net/projects/xdelta
- Andy On Friday 29 April 2005 12:44 am, Denis Zvonov wrote: > Hi guys, > > We found that when PROPPATCH is executed on a versionable resource a new > version (new file or VERSION_CONTENT record in case of RDBMS) of content > is produced too. This leads to inacceptable cloning of content which > leads to storage size growth. When we plan to store thousands or even > millions of files with the total volume of tenths of gigabytes, this > cloning becomes a very unpleasant... > > Can there be a way to write a storage or any other way not to clone > !_unchanged_! content? > > > Also there is another issue with Slide implementation. When we configure > Slide to store content in filesystem and all other things in Oracle, > content of previous versions is stored in Oracle anyway. There should be > allowed some history_content_store pluggable, I think. > > Another issue with Oracle store implementation. Revoking of privileges > from resources has error in SQL statement and does not work. > > We use Slide 2.1 > > Best regards. > Denis. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
