Hi, > On Tue, Dec 17, 2013 at 12:26 PM, Chetan Mehrotra > <[email protected]> wrote: > > So not sure where the fix is to be done. Should lock check be also > > restricted to version at which session is pinned or one needs to be at > > latest revision? > > Since the lock checks are normally used to synchronize work across > sessions, it doesn't make much sense for it *not* to refresh.
I definitively agree when it comes to locking a node. this should be done on a refreshed session. but what is the value in just checking if a node is locked? I don't think you can build reliable code with this behavior anyway. the lock status of a node may change as soon the isLocked() method returns and you cannot rely on what it reports. usually you have code that must modify content only with a lock held. in this case you will have to call lock() anyway, which performs a refresh. > Instead I'd look for a fix in steps 3 or 6: > > 3. Does the ImporterImpl really need to explicitly check for locking, > or would that be better handled by a commit hook? The same applies BTW > for the versioning check. > > 6. Since there's no need for a branch to be visible to any other > clients, a branch commit could (and probably should) remain in local > memory unless or until the transient space grows too large. This way > the performance overhead of the refresh should be minimal. not sure here, but I think the reason why we push the changes into the branch is that we can perform a rebase on the underlying store. e.g. the MicroKernel. how would you rebase a branch partially in memory and persisted? Regards Marcel
