On Aug 12, 2015, at 5:44 AM, Jacek Cała <jacek.c...@gmail.com> wrote: > > CONFLICT path/to/the/problematic/files/... - edited locally but deleted by > update > > As a result fossil did not delete all 102 conflicted files but left them in > my local working copy. That's not the best resolution, I think
Historically, Fossil never deletes working copy files on “fossil mv/rm”. This holds true when you merge one branch into another: when you update to the target branch, the deleted files reappear, then on “fossil merge” the old working copy files are left behind, even though they are no longer on the current branch in the repo. However, Fossil recently got an optional feature that — as I understand it — will become the default in Fossil 2.0. Meanwhile, in 1.x, you have to enable it in your Fossil binary first, with: $ ./configure --with-legacy-mv-rm $ make && sudo make install The option is named strangely, so I hope it changes, but it’s still named that way in trunk, as of [d17dc8f220] anyway. The option’s name doesn’t tell you what it actually does in Fossil 1.x, which is to enable a new setting, mv-rm-files, which when set causes “fossil mv/rm” to behave like Unix mv/rm: the working copy files are [re]moved at the same time the repo changes are scheduled, so you no longer need to do 2-step mv/rm. The interesting bit here is that with this option set, merging a branch with removed files also removes working copy files, as you expected it to. Fossil will be more consistent in its behavior when mv-rm-files becomes the default behavior. > It would prevent me doing 'pull' (equivalent of 'fossil update') and would > complain that the pull would destroy the local changes. I did some testing, and Fossil will indeed destroy local changes in such situations. It actually doesn’t require branches to do so. Test case: mkdir test cd test fossil init ../test.f f open ../test.f echo ‘Initial contents’ > foo f add foo f ci -m 'added foo' echo 'Changed foo' > foo f set mv-rm-files 1 f rm foo cat foo Result: foo disappears, along with your local changes! This is a bug. The solution is to fully implement the decision table in the Mercurial documentation for its rm command: https://www.selenic.com/mercurial/hg.1.html#remove Note that Mercurial demands -f to make it accept an rm command if there are local changes. Otherwise, Mercurial goes to state ‘W’, whereas Fossil currently goes to state ‘RD’. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
