Hello, I think that the current fossil implementation uses good techniques for ensuring that the data is properly saved into the repository. Even "Robust & Reliable" appear as head words in the front page.
Nevertheless, while I see a lot of care for the repository contents, I see little care for the local changes still not in the repository. By now, I've seen open: - On conflict of binary files locally, fossil overwrites local changes - The same for the case if an update operation removes a file with local changes; the file gets removed. - In those cases, fossil simply says, for example CONFLICT src/update.c - edited locally but deleted by update The last lines of the stdout saying: WARNING: 1 merge conflicts - see messages above for details. - Only 'fossil undo' can recover those file contents, and there is only one level of undo. If you run any operation that can be undone, it will overwrite that single level of 'undo' (correct me if I am wrong). - Some conflicts pass unnoticed, as I've reported some time ago: "'merge --backout' does not handle conflicts properly " http://fossil-scm.org/index.html/tktview?name=c26c63eb1b "If 'fossil update' brings in new files already present, it overwrites them silently" http://fossil-scm.org/index.html/tktview?name=45fccdcd61 I think the approach taken by most VCS I've seen is far better than what fossil provides now: leave the conflict files in the working directory with a different name, like it could be src/update.c.conflict for example. As I understand now, I've either to use the stash or commit somewhere and try the operations susceptible of file merges (update/merge) always with a working directory clean of changes. I personally dislike having to have this care. Any thoughts? Agreements? Disagreements? (And of course I'm writing this after just having lost some lines of code) Thank you, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
