I'd argue this is not intuitive, especially to a new Fossil user. "Losing" the file like this and not reporting at least as a warning seems like a wrong design choice, to me.
I actually like flagging the file as a conflict, with auto-resolution being to keep (re-add) the file. If this is tagged distinctively, then it is very easy - when you don't want the files re-introduced - to grep the output of 'fossil status' and bulk delete such files before committing the merge. But at least a warning would be very useful. We already have warnings when files don't have common ancestors while merging (the cause of which confused me enough times and is probably related to this). Richard, do you have a view on this? From: Scott Robison Sent: Friday, 17 April 2015 08:37 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 Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich <s...@stef.rs<mailto: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<mailto:w...@etr-usa.com>> wrote: > > On Apr 16, 2015, at 10:47 AM, Johan Kuuse <jo...@kuu.se<mailto: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<mailto: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<mailto: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
