Re: [fossil-users] fossil bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 6:11 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:34 PM, Matt Welland estifo...@gmail.com wrote: On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. In which case, the two files have nothing in common and the whole thing is one big merge conflict. Is that really helpful? Actually, this situation is known as a two-way-merge http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge and it is helpful in many cases. --Leo-- ___ 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 bug - same file created simultaneously in two work areas not merging properly
Uncovered a bug. In this case, two users working in their own fossil work
areas independently created a file with the same name. Each file is
unique. Fossil identifies that there is a conflict, but does NOT attempt
to merge the files. Commands to duplicate issue follow:
-jmg
##Script started on Wed 23 May 2012 10:22:54 AM MST
fossil init test.fossil
project-id: e3d111bd110a8cfccd49f5fda722dbafb2c05e72
server-id: 54ac75ed1002c3454a9d574c8848729720f6d867
admin-user: jmgedge (initial password is 2a508f)
mkdir area{1,2}
cd ./area1/
fossil open ../test.fossil
echo line1_area1 file_a.txt
echo line2_area1 file_a.txt
echo line3_area1 file_a.txt
cd ../area2/
fossil open ../test.fossil
echo line1_area2 file_a.txt
echo line2_area2 file_a.txt
echo line3_area2 file_a.txt
fossil set gmerge 'xxdiff %original %baseline %merge -M %output'
cd ../area1/
fossil add file_a.txt
ADDED file_a.txt
fossil commit -m area1 initial commit
New_Version: 025b2bc66c831dcb3499e7d6200e2aaa6aa7b0c2
cd ../area2/
fossil add file_a.txt
ADDED file_a.txt
fossil update
CONFLICT file_a.txt
--
updated-to: 025b2bc66c831dcb3499e7d6200e2aaa6aa7b0c2 2012-05-23
17:26:58 UTC
ags: trunk
comment: area1 initial commit (user: jmgedge)
fossil: WARNING: 1 merge conflicts
cat ./file_a.txt
line1_area2
line2_area2
line3_area2
___
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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell vi...@viric.namewrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. ___ 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 ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 3:11 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:34 PM, Matt Welland estifo...@gmail.com wrote: On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Lluís is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. In which case, the two files have nothing in common and the whole thing is one big merge conflict. Is that really helpful? Assuming that the work done in both files is important to the authors who wrote it I'd say yes. The solution for the auto-merge-with-conflict could be as simple as putting the contents of the one parent above the other with the usual merge markers. Creating an empty common ancestor file and the original and merge files would be helpful too as most folks probably rely on a gui merge tool which can handle this just fine. Currently it looks to the first person to commit as though their changes were discarded. The file is marked MERGED yet only contains content from the last person to add. Perhaps not something that will happen very often but the behavior is clearly wrong. Matt -=- ___ 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 ___ 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 ___ 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 bug - same file created simultaneously in two work areas not merging properly
Currently it looks to the first person to commit as though their changes were discarded. The file is marked MERGED yet only contains content from the last person to add. Perhaps not something that will happen very often but the behavior is clearly wrong. Unless I did something wrong while emulating the tests, the data is not discarded per se. One can move aside the new version of the file, update to get the old version and then manually do the merge. Was that not your experience? -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 4:34 PM, Matt Welland estifo...@gmail.com wrote: On Wed, May 23, 2012 at 1:28 PM, Richard Hipp d...@sqlite.org wrote: On Wed, May 23, 2012 at 4:23 PM, Llu?s Batlle i Rossell vi...@viric.name wrote: On Wed, May 23, 2012 at 01:16:08PM -0700, Justin Gedge wrote: Uncovered a bug. In this case, two users working in their own fossil work areas independently created a file with the same name. Each file is unique. Fossil identifies that there is a conflict, but does NOT attempt to merge the files. Commands to duplicate issue follow: How would fossil merge two files with no base data? What algorithm would do that? Thanks for the bug report. But I think Llu?s is right: There isn't anything Fossil (or any other DVCS) can do with situation, other than report the conflict to the user, which Fossil did do according to your log. So, unless somebody can suggest something better, I think that the current behavior is correct. It sounds to me that the common ancestor would be an empty file. In which case, the two files have nothing in common and the whole thing is one big merge conflict. Is that really helpful? YES!!! This would be helpful. If fossil is set to use xxdiff [or another utility] to merge conflicts- it becomes really obvious there is a conflict- and the resolution can be handled at the time of merge seamlessly. Even the conflict markers of a text mode would be usefull because the contents of both work areas are brought to the forefront. Using a blank file as a common ancestor and treating this situation as ``one big merge conflict'' would be useful. It removes steps of undoing [the merge], forking and merging forks in order to bring the contents together that were created in two different areas under the same file name. -jmg __ _ 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 ___ 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 d...@sqlite.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20120523/cf80c3d7/attachment.html -- ___ 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 bug - same file created simultaneously in two work areas not merging properly
On Wed, May 23, 2012 at 5:25 PM, Michael L. Barrow mlbar...@barrow.mewrote: Currently it looks to the first person to commit as though their changes were discarded. The file is marked MERGED yet only contains content from the last person to add. Perhaps not something that will happen very often but the behavior is clearly wrong. Unless I did something wrong while emulating the tests, the data is not discarded per se. One can move aside the new version of the file, update to get the old version and then manually do the merge. Was that not your experience? Yes, of course the old data is available and recovery is not hard. The behavior is still far from ideal in my opinion. You don't drop lines from a file with no visible hint to the user what data may be missing. I copied the script and ran it with some additional scenarios to see what would happen: 1. as test case was provided by Justin result: CONFLICT no hint inside the file of conflicting data. no launch of gui merge tool may or may not be easy to merge with gui merge tool 2. with all lines the same but for one result: CONFLICT no hint inside the file of conflicting data no launch of gui merge very easy to merge with a gui merge tool 3. with one line added at end of file result: CONFLICT no hint inside the file of the potentially missing line no launch of gui merge gui tools automatically merge these correctly. 4. identical files result: CONFLICT no merge necessary Every one of these cases is not handled well by fossil and there is no hint that data was dropped from view. I think a new user will be very confused by what they see. The 1st and 2nd case should have the conflict markers and or launch the merge gui. The 3rd case should probably be automatically merged with no CONFLICT warning. The 4th case should NOT report CONFLICT. -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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
