Hi @Hideman85,
If you are building a collaborative text / richtext application, you shouldn’t worry about manually cleaning up metadata (garbage collection). The gist of this article is that it is basically impossible for humans to create documents that are too large for Yjs (that is unless you are storing images or other large blobs in the file).
Can I force the garbage collection after cloning my document? Since I have versioned doc the GC is disabled on the documents but for the brand-new clone it would be really great to compact the document.
Yes, that is possible. You can disable garbage collection for tracking changes (or even only keep changes that are relevant for restoring versions). Once you create a new snapshot, you could store the non-gc’d document, reload it again with garbage-collection enabled and then disable garbage-collection again for tracking changes. If you want to load a certain version, you can load the specific snapshot. In order to load the non-gc’d document, you can load all document snapshots from beginning to end. nongcd = Y.mergeUpdates([version1, version2, version3]) The merged document has the complete version history of all changes.
Can I reset the clientID & PersistantUserData on all the current data? Basically, we want to see that the data is just pre-initialized data in the cloned doc. If we want to know more (and have the perm) we could just look the history of the parent.
Can you please clarify what you mean?
Then when we have clone can we easily take the update from one doc and put it in the other one?
Last question, a bit more tricky, can we cherry-pick an update/transaction and apply to the parent? I mean, I can do a lot of updates on it, but I just want to take some of them back to the parent.
It is generally not possible to cherry-pick specific changes from a version history (in the form of a document update) and apply them to another document. In some cases, this might work, but sometimes updates depend on each other. You always need to merge all changes from the diverged documents in the order in which they have been produced. Instead, you could work with a different representation for the changes (e.g. prosemirror transactions or the delta format.)
Cheers,
Kevin