good point.
I managed to do that for the indexing part (IndexHookManager
IndexHookManagerDiff). the diff is processed only once and then the changes
are delegated to each available impl.
I was thinking about applying the same principle to the entire commit hook
stack but I wasn't able to pull it
more info on what I had in mind, I was thinking that the majority of the
CommitHooks work on the same principle: the commit hooks creates a
NodeStateDiff implementation, then it applies the diff, next the new state
is returned.
My initial try was to shortcut this mechanism but allowing a
Hi,
We currently have half a dozen different commit hooks looking at each
commit. This means that each content diff is traversed at least half a
dozen times before the commit can be completed. As Thomas noted, this
causes a lot of extra reads especially with larger commits.
I'd like to try
Hi Jukka,
On 22/feb/2013, at 08:44, Jukka Zitting wrote:
Hi,
We currently have half a dozen different commit hooks looking at each
commit. This means that each content diff is traversed at least half a
dozen times before the commit can be completed. As Thomas noted, this
causes a lot of