On Thu, Jul 19, 2012 at 7:50 AM, Brad McEvoy <[email protected]> wrote: > I think the suggestion was to use timestamps locally just to determine > whether a local change has occured, and not the order of changes relative to > the server, which would be cool.
Yes. > However, that approach still misses the point of state token based sync. The > idea is to maintain a tree of directory hashes, and to perform > syncronisation simply by walking the tree from the root. When a directory > hash on the client is the same as the server you know everything under it is > perfectly identical, which makes timestamps irrelevant. "Directory hashes"? Are you referring to RFC6578 or a different method? I didnt see any mention of directories in the document. Though I do very much like the idea of assessing this problem hierarchically. > On 19/07/12 23:37, Klaas Freitag wrote: >> >> On 19.07.2012 13:09, Jono wrote: >> >> Hi, >> >>> I know we are steering away from using timestamps over the network, >>> but is it ok to use it locally? I can see problems with this when the >>> user decides to change their system clock, but maybe that is a >>> different issue. >> >> As long as both sides or repositories are on exactly the same time or do >> have a constant difference, mtimes are cool. But both is hard to achieve if >> you have network or even internet in between. Its achieveable with two local >> repos however, ie. on the same harddisk. >> >> regards, >> >> Klaas >> >> _______________________________________________ >> Owncloud mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/owncloud > > > > _______________________________________________ > Owncloud mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
