On Fri, Mar 30, 2012 at 2:18 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > On Fri, Mar 30, 2012 at 2:05 PM, Michael Dürig <mdue...@apache.org> wrote: >> I don't know about the details of the algorithm Git uses. But *if* that >> algorithm *does* reconstruct move and copy operations from looking at the >> raw trees, I'm pretty sure they annotated the trees in some ways to track >> that information. > > Ultimately it's just a comparison of matching content, see the -M and > -C options in git-diff(1). Git uses content hashes to optimize such > comparisons. > >> However, that doesn't solve the issue at hand. If we go down that route, why >> should we bother at all and reconstruct the operations from the state only >> to construct a JSOP statement to be given to Microkernel.commit()? We should >> rather do away with this entirely and pass the new tree directly to the >> Microkernel. > > Exactly. IMHO we should adjust the MK interface to support this. The > solution should also address handling of large imports.
sorry, i can't follow you here. could you please elaborate? cheers stefan > >>> More generally, what's the use case where this functionality is >>> needed? I'd be happy to even drop support for NODE_MOVED observation >>> events unless we have real clients that actually require that >>> information (as opposed to just create/update/delete events). >> >> I'd be fine with that. However, if clustering relies on journal scrapping, >> this is not an option. > > Good point. Intuitively I'd be fine with placing such a restriction on > the underlying clustering implementation, though it would be really > nice if we had some performance/scalability figures to back that > assumption. > > BR, > > Jukka Zitting
