Re: [fossil-users] Merge - including files from other branches - best practice?
On Fri, 17 Apr 2015 06:56:13 +0200, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600: Partly I think it is because your test case consists of a single file of a single line, which means probably (I would think) every merge resulted in a conflict that you had to resolve manually. Yes, every merge is a conflict which I resolve arbitrarily by leaving just one of the conflicting changes. Effectively, the line from newbranch was deleted and the line from trunk was inserted, so by the time of the merge there is nothing new or changed in newbranch to merge into trunk. That's effectively what seems to be happening. Even though ``file'' is different on newbranch, when I merge it into trunk, it doesn't consider the contents of ``file'' as being in conflict---which surprised me. All other merges resulted in conflict resolution that had to happen. So I was expecting conflict resolution when I merged in the branch---there was none. I'm still a bit confused why it didn't think there was a conflict and just chose instead to take the content from trunk (which is why it shows no differences). +1: I, too, don't really get it, why a file deletion should be treated differently from edits to the file (including the case where an empty file would be the result). at merge time, all conflicting differences between both branches should be reported and would nee manual resolution. so if `foo' had been deleted in the past on trunk and later a new file of that name is created on the branch, it would seem correct to handle this as a conflict just as if `foo' still where in existence on trunk whereas if `foo' never has existed on trunk in the first place, the new file from the branch should simply be merged as a non-conflicting difference. what am I missing? Thanks for your response. Andy -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Merge - including files from other branches - best practice?
Hi, This is probably a trivial question, but I can't find a clear answer in the documentation. I have a repository at http://kuu.se/fossil/b64.cgi/timeline with two branches, trunk and c-stdin In c-stdin, I created the file b64.c, which does not exist in trunk. Some other files, created beforehand in trunk, were modified in c-stdin. The changes in c-stdin were then merged into trunk, as seen in http://kuu.se/fossil/b64.cgi/info/4e0d851bb88275cf056686c4c3e161bee84647ea In this case, b64.c was not merged into trunk. Of course I could have simply add an empty file named b64.c in trunk before merging, but I don't think that is the way to do this correctly. In this case we are talking about one single file, which makes it easy to do manually. But what if there were thousands of files in each branch? I am looking for an option similar to: fossil update trunk fossil merge c-stdin --include-missing-files Sorry if I am missing something trivial in the documentation. Any suggestions appreciated. Regards, Johan ___ 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] Merge - including files from other branches - best practice?
On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.se wrote: In c-stdin, I created the file b64.c That’s not what this says: http://kuu.se/fossil/b64.cgi/finfo?name=b64.c I’ve done what you claim to have attempted, and if you had actually done this, you would have seen something like ADDED_BY_MERGE in the commit message commentary when you gave the “fossil merge” command. ___ 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] Merge - including files from other branches - best practice?
On Apr 16, 2015, at 2:44 PM, Warren Young w...@etr-usa.com wrote: On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.se wrote: In c-stdin, I created the file b64.c That’s not what this says: Also, notice that the checkin that claims to have created b64.c actually modifies the copy created on the trunk: http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070 ___ 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] Merge - including files from other branches - best practice?
Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600: It is by design. Merging isn't always intuitive, and certainly there could be a bug in it. Perhaps like this one: http://fossil.bradfords.org:8080/info/b1e9974a37c648fe Why was that merge essentially a no-op? I'm confused... Thanks, Andy -- TAI64 timestamp: 400055306ce8 ___ 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] Merge - including files from other branches - best practice?
Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600: Partly I think it is because your test case consists of a single file of a single line, which means probably (I would think) every merge resulted in a conflict that you had to resolve manually. Yes, every merge is a conflict which I resolve arbitrarily by leaving just one of the conflicting changes. Effectively, the line from newbranch was deleted and the line from trunk was inserted, so by the time of the merge there is nothing new or changed in newbranch to merge into trunk. That's effectively what seems to be happening. Even though ``file'' is different on newbranch, when I merge it into trunk, it doesn't consider the contents of ``file'' as being in conflict---which surprised me. All other merges resulted in conflict resolution that had to happen. So I was expecting conflict resolution when I merged in the branch---there was none. I'm still a bit confused why it didn't think there was a conflict and just chose instead to take the content from trunk (which is why it shows no differences). Thanks for your response. Andy -- TAI64 timestamp: 400055309290 ___ 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] Merge - including files from other branches - best practice?
On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600: It is by design. Merging isn't always intuitive, and certainly there could be a bug in it. Perhaps like this one: http://fossil.bradfords.org:8080/info/b1e9974a37c648fe Why was that merge essentially a no-op? Partly I think it is because your test case consists of a single file of a single line, which means probably (I would think) every merge resulted in a conflict that you had to resolve manually. Here is what I think is happening: [1413f8301f] on trunk leads to [793622de13] on newbranch leads to [2b0c514af3] on newbranch [ec781a493d] on trunk At this point trunk is merged into newbranch resulting in [d228092800]. There had to have been a conflict and the merge was resolved as taking the line from trunk, not newbranch. At this point newbranch has a single file with a single line that came from trunk. There are 5 more commits before [b1e9974a37] which merges newbranch back into trunk, and since newbranch came from trunk during conflict resolution, the nearest common ancestor came from trunk, so trunk wins. Effectively, the line from newbranch was deleted and the line from trunk was inserted, so by the time of the merge there is nothing new or changed in newbranch to merge into trunk. Note that I have not deconstructed and played back all these changes. I have looked at all of the commits though and this is the best I think one can expect a merge algorithm to do with the lines in question. -- Scott Robison ___ 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] Merge - including files from other branches - best practice?
On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich s...@stef.rs wrote: I think what happened is that the file got deleted in the trunk (by another merge) and the OP expected it to be re-added by the last merge because the file was there. Is this by design? I would've expected it too. It is by design. Merging isn't always intuitive, and certainly there could be a bug in it. I thought I'd found one a month or so ago but after debugging and going through the code with a fine toothed comb, I realized I was wrong. It was related to edits to the same file in the same place and it was not obviously why previously merges had made certainly lines of code unavailable in the merge conflict resolution. Consider this (commits are assumed to happen at each stage): 1. Trunk commit includes file foo. 2. Branch is created from trunk (which includes foo). 3. Edits are made on branch. 4. Merged from branch to trunk (edits now reflected on trunk). 5. File is removed from trunk. 6. More edits are made on branch. 7. Merged from branch to trunk (there is no foo in trunk to which to apply the edits, and foo was not *added* to the branch). Believe me, I understand, merging is not always intuitive if you don't have absolute complete awareness of the state of all files in both branches in every commit on each branch. In this case, the fact that the file was removed from trunk meant there was no where to put the edits from the branch. The only other way of resolving this would be to give some sort of merge conflict that the edits from branch are to an empty file on trunk, but then one could argue I deleted foo from trunk, don't waste my time with conflict resolution reports. SDR Original Message From: Warren Young Sent: Friday, 17 April 2015 06:46 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Merge - including files from other branches - best practice? On Apr 16, 2015, at 2:44 PM, Warren Young w...@etr-usa.com wrote: On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.se wrote: In c-stdin, I created the file b64.c That’s not what this says: Also, notice that the checkin that claims to have created b64.c actually modifies the copy created on the trunk: http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070 ___ 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 -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
