Hi, Many thanks for your answers, it turns out I got extremely confused by not paying enough attention to a fossil warning.
* Richard Hipp <d...@sqlite.org> [20110719 00:52]: > On Mon, Jul 18, 2011 at 6:41 PM, Joan Picanyol i Puig < > lists-fos...@biaix.org> wrote: > > > I've stumbled upon a situation in which fossil's "latest wins" merge > > strategy and a system's "far-in-the-future" clock have messed up my > > content & timeline. I do recall fossil's warning regarding out-of-synch > > clocks when synching, but thought that it would DTRT since the files > > being modified in that system where unrelated to the files being > > modified in the server against which it was synching. > > > > I don't really understand your problem. I get the part about you having > make some check-ins with far-in-the-future timestamps. But Fossil doesn't > have a "latest wins merge strategy". So I'm not sure where that is causing > a problem. "latest wins merge strategy" has shown to be a poor word choice: I did not invoke 'fossil merge' at all (I haven't branched). All work was done in the same (and only) branch, just on diferent systems with out-of-sync clocks. > When you try to reference a check-in by its branch name, Fossil actually > chooses the check-in of that branch with the latest timestamp. So, if you > have some check-ins which are far in the future, those check-ins might be > selected when you use the branch name, even though they are not the last > check-ins in sequence. Is that what you are having problems with? (That > has nothing to do with merging, though, which is why I don't really > understand the problem.) This might indeed be the issue, what surprised me is that fossil couldn't DTRT. When I refered to concrete artifacts/manifests I was referencing them by their hash in 'fossil diff --from x --to y'. > Another solution is to use the "edit" feature of the web interface to > manually change the timestamps of the far-in-the-future check-ins to > something more reasonable. Wow! Talk about rewriting history :p This did the trick: the timeline looks back to normal *and* the content as shown through the "embedded doc" URL is the same as on the filesystem. * Ron Wilson <ronw.m...@gmail.com> [20110719 02:10]: > I think what Joan is refering to is this, from the Fossil documentation: > > "Wiki pages can branch and merge just like check-ins, though as of > this writing (2008-07-29) there is no mechanism in the user interface > to support branching and merging. The current implementation of the > wiki shows the version of the wiki page that has the most recent > timestamp." > > So I think that manually fixing the timestamps will correct the problem. Indeed, manually fixing the timestamps has corrected the problem. I believe the lesson learned (for me) is that "embedded doc" is not part of the version graph. However, the fact that a file is different on the filesystem than through the web interface I believe should be considered a bug, it is way too confusing. tks, and keep up the good work -- pica _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
