@eric.vanbeest: Saving in RapidWeaver 4.0 should not be that much slower than RapidWeaver 3.6.7, and for big sites, it should actually be a reasonable amount faster. If you’re seeing significantly bigger save times with 4.0, please report a bug so that we can fix it for you.
The disk space story is a lot more complex. If your site was 6MB with RapidWeaver 3.6, seeing it expand to 42MB with 4.0 is not unusual. However, the disk space that the site uses is actually quite deceptive: while the size of the 4.0 document is 42MB, chances are that the actual disk space your site takes up is not much bigger than the original 6MB. We use a Mac OS X feature named “hard links” to save space and speed up file saving.
If you load a 4.0 document with 1000 blog entries, only change one entry in it, and re-save it (replacing the existing document), RapidWeaver actually won’t save 1000 blog entries: it’ll only save the single new entry that you changed, and re-use the 999 old entries. If you save it as a new document, the 999 entries that didn’t change will actually be shared between the two documents. So, if your old file was 1000MB and you save it to a new file that 1001MB, 999MB of the data between the two is actually shared, so your new file actually only takes up an extra 2MB on disk. If you delete one of the documents, even though the data’s shared between them, the other document’s contents will remain fully intact.
Also, some plugins that are optimised for 4.0 will take advantage of this data-sharing idea to embed a lot more data in your document. I’m pretty sure that Collage 2 will actually store all your images in the RapidWeaver document now (so that if your original images get lost, your Collage album will still work). However, since Collage 2 is using hard links to share data, it won’t actually take up any extra space on your disk.
However, this may not be the case all the time. If you’re saving to a networked home directory or a Firewire/USB drive, the data sharing may not work. (The geek speak is that the source document and the destination document must reside on the same filesystem that supports hard links, and it depends on whether the plugin needs to use temporary directories on the local filesystem to store intermediate data.)
Hope that helps,
Andre.
(which Google likes) and I could delete all those extra rw_common folders which were a workaround for blog and photo albums.
