On Mar 17, 2011, at 11:00 AM, "johnfound" <[email protected]> wrote: > On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov > <[email protected]> wrote: >> >> That is, my understanding is that it's check-ins (changesets) that are >> versioned, not files, and so it's the relations between check-ins which >> are considered when doing merges. > > If so, then using "fossil update ?VERSION? ?FILES" syntax violate the > "Principle of least astonishment".
The trouble with the principle of least astonishment is how unpredictable people's astonishment can be. Changing a particular file or files in my checkout to the version of those files in some past or other branch is not a daily need, but I wouldn't call it rare for me. SVN actually does keep track of the revision of individual files, which I always found actually got in my way when all I want to do is replace a file with a previous version. There may be an easier way, but in SVN I always ended up copying and pasting the file contents from a graphical history view. So a former SVN user could easily find the fossil behavior astonishing. It wasn't astonishing to me, and it was a welcome change, but then I had some intervening DVCS experience. Git has no 'update' but uses the checkout verb for switching to a different commit, and like fossil git allows you to checkout only specific files of a given revision. When you do, it behaves just like fossil update VERSION FILES--the file is changed, but no record is kept of what version it came from. I don't consider this a bug, and I would really hate to lose this capability I don't care if it gets a different name, though, if that satisfies others _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
