Re: [fossil-users] Fossil omits the updates through update command.
On Fri, Mar 18, 2011 at 12:12 PM, John Found johnfo...@evrocom.net wrote: For me least astonishment means simply: If the file is changed by VCS, then later, VCS must knows about this fact and must take it into account. If the user changed the file by any other way (edit, copy paste, etc.) VCS should consider this file edited. Any other variant is acceptable only if the VCS additionally detects some kind of edits, made by the user - for example moving, renaming or deletion of the files. IMHO, omiting actions, explicitly declared by command is not acceptable. I think for most people, least astonishment means the tool (for whatever tool) did what they wanted it to do. Usually, I am astonished when the tool does what I wanted for any operation other than the basics. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
-- Original Message -- To: fossil-users@lists.fossil-scm.org (fossil-users@lists.fossil-scm.org) From: Joshua Paine (jos...@letterblock.com) Subject: Re: [fossil-users] Fossil omits the updates through update command. Date: 17.3.2011 18:59:54 On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote: On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net 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. I have very little experience with any version control systems. For me least astonishment means simply: If the file is changed by VCS, then later, VCS must knows about this fact and must take it into account. If the user changed the file by any other way (edit, copy paste, etc.) VCS should consider this file edited. Any other variant is acceptable only if the VCS additionally detects some kind of edits, made by the user - for example moving, renaming or deletion of the files. IMHO, omiting actions, explicitly declared by command is not acceptable. http://fresh.flatassembler.net Assembly language visual programming. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil omits the updates through update command.
I am pretty sure it is a bug. When you update some file using update command, fossil does not account this relation later, when it searches for the nearest common ancestor. As a result, it counts the update as an edit and later fails to merge the files properly. This behavior is illustrated in the test repository here: https://chiselapp.com/user/johnfound/repository/bad_update_test/timeline It contains only one file A.txt. Two branches, containing the test ground - trunk and Br2, and the branch BadMergeResults that contains the conflicting files after the last merge attempt. Regards ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
On Thu, Mar 17, 2011 at 5:20 AM, johnfo...@evrocom.net wrote: I am pretty sure it is a bug. When you update some file using update command, By update some file, I am guessing you mean that you did fossil update VERSION FILE1 Rather than just fossil update VERSION If so, then you are right - the base version number is not changed when you update individual files. All that a file-update does is make edits to the file. I am not inclined to fix this. If it is confusing, my preferred fix would be to take away the ability to update individual files. Fossil could, in theory, be enhanced to keep track of the base version for individual files. But that would be a rather large and complex change and would be difficult to test. You can accomplish the same thing by doing a commit in between your file-update and your additional merges. Make it a commit --private if you don't want to share the intermediate results with the world. fossil does not account this relation later, when it searches for the nearest common ancestor. As a result, it counts the update as an edit and later fails to merge the files properly. This behavior is illustrated in the test repository here: https://chiselapp.com/user/johnfound/repository/bad_update_test/timeline It contains only one file A.txt. Two branches, containing the test ground - trunk and Br2, and the branch BadMergeResults that contains the conflicting files after the last merge attempt. Regards ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
The problem is not because fossil doesn't track the individual files base version, but because fossil fails to determine properly the nearest common ancestor of the file. In my example, after the update, the nearest common ancestor, in fact, is [18a3dfdd], but when fossil makes merge, it continues to consider [0a5a95eb] as nearest common ancestor. IMHO, that is why it fails to merge properly. On the other hand, when I browse the file history, the graph is correct: https://chiselapp.com/user/johnfound/repository/bad_update_test/finfo?name=A.txt It means fossil knows the history of the file and still consider nearest common ancestor to be the wrong file. ...or I still can't understand something? So, please explain then. Regards On Thu, 17 Mar 2011 07:56:35 -0400, Richard Hipp d...@sqlite.org wrote: On Thu, Mar 17, 2011 at 5:20 AM, wrote: I am pretty sure it is a bug. When you update some file using update command, By update some file, I am guessing you mean that you did fossil update VERSION FILE1 Rather than just fossil update VERSION If so, then you are right - the base version number is not changed when you update individual files. All that a file-update does is make edits to the file. I am not inclined to fix this. If it is confusing, my preferred fix would be to take away the ability to update individual files. Fossil could, in theory, be enhanced to keep track of the base version for individual files. But that would be a rather large and complex change and would be difficult to test. You can accomplish the same thing by doing a commit in between your file-update and your additional merges. Make it a commit --private if you don't want to share the intermediate results with the world. fossil does not account this relation later, when it searches for the nearest common ancestor. As a result, it counts the update as an edit and later fails to merge the files properly. This behavior is illustrated in the test repository here: https://chiselapp.com/user/johnfound/repository/bad_update_test/timeline [2] It contains only one file A.txt. Two branches, containing the test ground - trunk and Br2, and the branch BadMergeResults that contains the conflicting files after the last merge attempt. Regards ___ fossil-users mailing list fossil-users@lists.fossil-scm.org [3] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users [4] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
On Thu, 17 Mar 2011 15:05:13 +0200 johnfo...@evrocom.net wrote: The problem is not because fossil doesn't track the individual files base version, but because fossil fails to determine properly the nearest common ancestor of the file. In my example, after the update, the nearest common ancestor, in fact, is [18a3dfdd], but when fossil makes merge, it continues to consider [0a5a95eb] as nearest common ancestor. IMHO, that is why it fails to merge properly. On the other hand, when I browse the file history, the graph is correct: https://chiselapp.com/user/johnfound/repository/bad_update_test/finfo?name=A.txt It means fossil knows the history of the file and still consider nearest common ancestor to be the wrong file. ...or I still can't understand something? So, please explain then. I think a typical DVCS finds common ancestor using whole check-ins and it appears that fossil is no different in this regard. So if you did a local edit to your file and then committed this change, fossil simply does not record the fact your local edit resulted from [fossil update] and not from direct modification using a text editor or by some other means. 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Thu, 17 Mar 2011 15:05:13 +0200 johnfo...@evrocom.net wrote: The problem is not because fossil doesn't track the individual files base version, but because fossil fails to determine properly the nearest common ancestor of the file. In my example, after the update, the nearest common ancestor, in fact, is [18a3dfdd], but when fossil makes merge, it continues to consider [0a5a95eb] as nearest common ancestor. IMHO, that is why it fails to merge properly. On the other hand, when I browse the file history, the graph is correct: https://chiselapp.com/user/johnfound/repository/bad_update_test/finfo?name=A.txt It means fossil knows the history of the file and still consider nearest common ancestor to be the wrong file. ...or I still can't understand something? So, please explain then. I think a typical DVCS finds common ancestor using whole check-ins and it appears that fossil is no different in this regard. So if you did a local edit to your file and then committed this change, fossil simply does not record the fact your local edit resulted from [fossil update] and not from direct modification using a text editor or by some other means. 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. It looks like the file is updated by fossil (so fossil have to track this update in the future), but actually it later acts like the file is edited by the user... So, this option would be better to be removed from the update command. On the other hand I would like to have option to say to fossil not to copy group of files from one branch to another and not to try to merge. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote: On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
What can you do with: fossil update ?VERSION? FILES... That you cannot do easily with? fossil revert ?-r REVISION? ?FILE ...? Or I am missing something or fossil update files... is redundant. RR 2011/3/17 Joshua Paine jos...@letterblock.com: On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote: On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil omits the updates through update command.
Fossil update will 'move' your changes as well, if you have any. Revert will just overwrite the file, and you will lose the changes. I also agree that the difference between fossil update and fossil update files is a bit confusing. But rather then removing the feature, I'd just print an info message saying 'current checkout changed to ...' or 'current checkout did not change'. Currently, there is no way to tell the difference from the output of the command; you have to do fossil info to realize this. On Thu, Mar 17, 2011 at 1:15 PM, Ramon Ribó ram...@compassis.com wrote: What can you do with: fossil update ?VERSION? FILES... That you cannot do easily with? fossil revert ?-r REVISION? ?FILE ...? Or I am missing something or fossil update files... is redundant. RR 2011/3/17 Joshua Paine jos...@letterblock.com: On Mar 17, 2011, at 11:00 AM, johnfound johnfo...@evrocom.net wrote: On Thu, 17 Mar 2011 16:22:22 +0300, Konstantin Khomoutov flatw...@users.sourceforge.net 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
