On Mon, Feb 6, 2012 at 2:27 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > On Mon, Feb 6, 2012 at 1:53 PM, Michael Dürig <mdue...@apache.org> wrote: >>> An alternative that AFAICT achieves the same effect in perhaps an >>> easier to understand manner would be to use the state of the content >>> tree instead of changes to that state as the key concept. [...] >> >> That's more or less what I started with [1] and what I referred to as can of >> worms in my original mail. Detecting and normalizing/consolidating moves >> turned out to be too tricky there. You basically have the same cases I >> identified (1. - 16.) but its much more difficult to tell them apart. > > Instead of separate Added/Existing/Moved/Removed instances in the > ChangeTree, did you consider keeping the modified content just as > (say) TransientNode instances, without trying to keep track of how > they came to exist? Then, when you actually need the change log, you > should still be able to construct it by diffing the transient tree > against the persistent base state of the content tree. The only caveat > I know of is that moves can only be reliably detected for > referenceable nodes or ones with an equivalent internal unique ID > (which we shouldn't have trouble doing if needed).
BTW, that's how it the transient space is implemented in the current jackrabbit-core. cheers stefan > > BR, > > Jukka Zitting
