Hello all!
I ran into some odd behavior with running revert on a checkout in which a
rename has just been performed. The renamed file gets deleted, but the
original file doesn't get restored. No changes are reported by 'fossil
changes', although the checkout is certainly not in its original state. The
fastest way to do that is to just close and reopen the repo. Alternatively,
you could run undo, rename the file back, and then run revert again. That
would get more annoying if you had renamed multiple files, obviously. I also
noticed that you can recover the original file by calling revert on the
original filename, but then fossil appears to see it as a new file (it
appears as ADDED in the output of 'fossil addremove --test').
This should be easy to reproduce. Just create a repo and commit a file into
it. Then change that file's name and run 'fossil mv'. Finally, run 'fossil
revert' and you should see the behavior I've described.
Is this the proper behavior for revert? Is there a different way I should
handle this scenario? Is this a legitimate bug that I should file a ticket
for (I couldn't find an existing one)? Am I a moron? The answer to one of
these questions is certain to be "yes!"
Thanks for the help!
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
