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
Re: [fossil-users] Merging deleted files (Was: Merge - including files from other branches - best practice?)
I can imagine a lot of people being annoyed if auto resolution was to add a file previously deleted from a branch back to the branch. I can see that being every bit as confusing to them as it not being re-added is to you. Just as my deleted text a month ago was to me. The difference is that re-adding is showing up in 'fossil status', which is then easy to reverse by grepping it's output and piping to delete before commit; while for no-op, as currently is the case, you are not aware there is a potential problem at all. And if/when you figure out that files are missing, you'd have to resurrect and manually add them one by one. But I wouldn't mind if, instead of no-op, status just shows that the ancestor was removed and current edits are therefore ignored. I can then equally grep for it and then bulk add it, if necessary. It would be interesting to know what others on the list think. It would be more cumbersome to describe, in my opinion - see below example. I think the crucial thing here is the distinct indicator by the merge that this situation is encountered, so you can then choose to act if appropriate. How it is auto-resolved is less important. For example, this indicator could be a status like 'CONFLICT', but would be auto-resolved to allow commit. For example, 'READDED_BY_MERGE' or, in your case, 'KEPT_DELETED_BY_MERGE' or 'IGNORED_CHANGES_ANCESTOR_MISSING'. On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich s...@stef.rsmailto:s...@stef.rs wrote: ?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'd agree it is not intuitive, as it took some hours of my time when I thought I'd found a bug a month ago to trace through the code looking for a flaw that didn't exist. I had told it at one point in time to merge in a deletion into my branch, and so when it came time to play catch up to trunk, it did what I had told it to do previously: Keep text previously deleted out of the new merge, even though in this case I needed to readd something due to other changes in fossil. 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. I can imagine a lot of people being annoyed if auto resolution was to add a file previously deleted from a branch back to the branch. I can see that being every bit as confusing to them as it not being re-added is to you. Just as my deleted text a month ago was to me. 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). How about this scenario: 1. Trunk is the mainline branch from which releases are made. 2. Feature is a branch for ongoing development of some feature. 3. Periodically you merge trunk into feature so that you don't drift too far (up to and including just before the final merge back to trunk). 4. In the end, you merge from the feature back to trunk when everything is ready for release. I think in this case you'd get the warning you seek because in the parent branch it had been deleted while being edited in the child branch (the nearest common ancestor was on trunk). I think you're right about the common ancestor confusion. I certainly can see the point about deletion from one branch and edits in another branch being arguably a conflict requiring resolution. I'm just can't think of a better way to handle it than at present. This is probably why I don't get paid the big bucks. -- 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] Two trunks?
On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote: On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org wrote: And a fork that ends in being merged is also no longer a fork. I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? You can still create commits from it, but update will move past it. That's why it is no longer a fork. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bug? FOSSIL MV does not work as expected (Win7 machine)
This is on a Win7 machine (if it matters). A simple way to reproduce (f = fossil): f new xxx.fossil f o xxx.fossil mkdir a\a dir a\a\xxx f add a f com -m Initial f mv a\a b f close Based on help screen, and usual behavior of mv, I would expect subdirectory a\a to be now known as b, and of course all files below to move accordingly. But nothing happens. If I move each file separately, it works. This is what the help screen shows: Usage: f mv|rename OLDNAME NEWNAME or: f mv|rename OLDNAME... DIR Move or rename one or more files or directories within the repository tree. You can either rename a file or directory or move it to another subdirectory. ___ 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] Two trunks?
2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger jo...@britannica.bec.de: On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote: On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org ... I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? You can still create commits from it, but update will move past it. That's why it is no longer a fork. Let's try that with a branch which is recently merged to trunk: $ fossil update update-fork-warn updated-to: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10 17:33:18 UTC leaf: closed tags: update-fork-warn comment: Only check for forks on open leaves, otherwise we cannot do anything about it from here anyway. Thanks to Andy Bradford for noticing this. (user: jan.nijtmans) changes: 13 files modified. fossil undo is available to undo changes to the working checkout. $ fossil update checkout: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10 17:33:18 UTC leaf: closed tags: update-fork-warn comment: Only check for forks on open leaves, otherwise we cannot do anything about it from here anyway. Thanks to Andy Bradford for noticing this. (user: jan.nijtmans) changes: None. Already up-to-date Looks like that statement is not true! fossil update will only move past it if the branch-name didn't change. I think Andy was right in his statement: the only three ways a fork can be resolved is: 1) fossil merge without any arguments, merging the two tips of the fork together. 2) fossil merge --integrate branchname: merging to another branch, while implicitely closing branchname. 3) fossil tag --raw closed uuid (or close it with the UI) So, a merge which merges the two tips of a fork together indeed closes the fork. But for other merges more needs to be done, that's how it functions (as it should). Sorry ;-) Regards, Jan Nijtmans ___ 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] Two trunks?
On Fri, Apr 17, 2015 at 01:07:50PM +0200, Jan Nijtmans wrote: 2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger jo...@britannica.bec.de: On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote: On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org ... I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? You can still create commits from it, but update will move past it. That's why it is no longer a fork. Let's try that with a branch which is recently merged to trunk: Right, but different. As discussed earlier, a fork means more than one leaf for the same branch. My point is that a merge of a fork will be passed over by update. In this case the branches are by definition the same. Joerg ___ 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] terminology confusion
github calling the project clone maintained on the server side a fork (I believe that's what it is, right?). 100% correct; a Github fork is a server-side clone. A Github fork is also part of the project fork network. This membership allows you to propose changes from your copy of the project to another repository copy in the network - this is the pull request. Normally you propose changes to the initial upstream repository from which you forked, but you can also generate pull requests from your fork to any other repo in the fork network. -J ___ 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] Merging deleted files (Was: Merge - including files from other branches - best practice?)
On 4/16/15, Steve Stefanovich s...@stef.rs wrote: Richard, do you have a view on this? I am following this conversation closely, as well as the discussion regarding forks. But I don't have any free cycles available to work on this, or even to comment on it, at the moment. -- 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] Two trunks?
On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: As discussed earlier, a fork means more than one leaf for the same branch. And merging the leaf of a branch to another branch (maybe trunk) does not make that leaf not-a-leaf. So why should merging a fork-leaf to whatever make the fork-leaf not a fork? ___ 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] terminology confusion
Fossil simply defines it: Having more than one leaf in the check-in DAG is called a fork. After re-reading the wiki section that you pointed out I have a much better understanding of how Fossil defines a fork. Thanks for pointing that out. What I'm surprised at, after following both discussions, is I don't recall seeing this mentioned, but perhaps it was: *Fork* A fork is when a check-in has two or more direct (non-merge) children in the same branch. And then the example text: Check-in 2 of figure 3 is considered a fork because it has two children in the same branch. Check-in 2 of figure 5 also has two children, but each child is in a different branch, hence in figure 5, check-in 2 is considered a branch point. Figure 3: https://www.fossil-scm.org/index.html/doc/trunk/www/branch03.gif Figure 5: https://www.fossil-scm.org/index.html/doc/trunk/www/branch05.gif My interpretation of fork was an unmerged leaf on the same branch - which is incorrect, according to the docs. This was also the reason I suggested head as a Mercurial analog. In the oft cited example of a fork in 2015 (which happens to be related to my check-in submitted by bundle export/import). My check-in is not actually the fork; the parent of my check-in is the fork. To use Ron's road analogy, if I am driving a car and I come to a fork in the road I can go left or right or however many road choices I have. The fork is the point at which I make a choice. Whichever road I choose, I drive through the fork/branch point and I am now just on a road - maybe the road ends quickly (leaf), maybe it keeps going (branch). The distinction between fork and branch point then becomes important as it gets to intent. *Branch Point* A branch point occurs when a check-in has two or more direct (non-merge) children in different branches. A branch point is similar to a fork, except that the children are in different branches. So a leaf is never a fork; it is just a leaf. Sorry if am restating what was obvious to everyone else. -J ___ 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] How about renaming a fork to fork-*? (Was: Two trunks?)
Hello, Did you mean for your reply to go only to me? You did not CC the Fossil list. On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich s...@stef.rs wrote: *From: *Ron W *Sent: *Friday, 17 April 2015 11:04 *To: *Fossil SCM user's discussion *Reply To: *Fossil SCM user's discussion *Subject: *Re: [fossil-users] Two trunks? On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.org wrote: And a fork that ends in being merged is also no longer a fork. I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? Closing it or making it the start of a new, named branch explicitly indicate an intent to remove fork status. ___ 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] Can fossil be used to apply a diff patch?
Can fossil be used to apply a diff patch (such as that created by the diff 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] Can fossil be used to apply a diff patch?
On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote: Can fossil be used to apply a diff patch (such as that created by the diff command)? Fossil itself doesn’t do that. You use the patch(1) utility for that, which expects a unified diff. (“fossil diff” produces output in that format by default, but diff(1) does not.) If you want something that works entirely with Fossil tools, you should be using the new “bundle” features. This creates a “sub-repository” containing a given change set, including all of the details Fossil tracks that do not appear in “fossil diff” output. ___ 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] Can fossil be used to apply a diff patch?
Note also that you can tailor your diff output w/ fossil set diff-command eg: fossil set diff-command diff -bu On 4/17/15, Warren Young w...@etr-usa.com wrote: On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote: Can fossil be used to apply a diff patch (such as that created by the diff command)? Fossil itself doesn't do that. You use the patch(1) utility for that, which expects a unified diff. (fossil diff produces output in that format by default, but diff(1) does not.) If you want something that works entirely with Fossil tools, you should be using the new bundle features. This creates a sub-repository containing a given change set, including all of the details Fossil tracks that do not appear in fossil diff output. ___ 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] Can fossil be used to apply a diff patch?
Thank you but I wanted this for a Win7 machine, not Linux. (I have MINGW installed but its 'patch' is a bit unstable as it crashes most of the time besides not being available on most Win7 machines.) That's why I was hoping fossil would be able to eat its own ... diff Bundle is not good when the patch comes from a 3rd source (e.g., posted on a web site) in unified diff format, and there's nothing you can do about it. Thanks, anyway. I guess I need to look for a reliable Win7-based stand-alone patch utility. Until then, manual editing! :) -Original Message- From: Warren Young Sent: Saturday, April 18, 2015 12:31 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Can fossil be used to apply a diff patch? On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote: Can fossil be used to apply a diff patch (such as that created by the diff command)? Fossil itself doesn’t do that. You use the patch(1) utility for that, which expects a unified diff. (“fossil diff” produces output in that format by default, but diff(1) does not.) If you want something that works entirely with Fossil tools, you should be using the new “bundle” features. This creates a “sub-repository” containing a given change set, including all of the details Fossil tracks that do not appear in “fossil diff” output. ___ 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] How about renaming a fork to fork-*? (Was: Two trunks?)
Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, but just the quote without my reply). What I meant to say here is that the whole confusion about forks is due to the fact that they branch out under the same tag. I can't see the case where is this ever desirable. How about if the fork happens, simply change the tag automatically to 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just tag it as 'fork', on commit? That would be very visible, either prompting people to merge back and close the fork, or to rename the 'fork-' tag to meaningful branch name. From: Ron W Sent: Saturday, 18 April 2015 03:00 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two trunks?) Hello, Did you mean for your reply to go only to me? You did not CC the Fossil list. On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich s...@stef.rsmailto:s...@stef.rs wrote: From: Ron W Sent: Friday, 17 April 2015 11:04 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Two trunks? On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote: And a fork that ends in being merged is also no longer a fork. I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? Closing it or making it the start of a new, named branch explicitly indicate an intent to remove fork status. ___ fossil-users mailing list fossil-users@lists.fossil-scm.orgmailto: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] Fw: How about renaming a fork to fork-*? (Was: Two trunks?)
Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, but just the quote without my reply). What I meant to say here is that the whole confusion about forks is due to the fact that they branch out under the same tag. I can't see the case where is this ever desirable. How about if the fork happens, simply change the tag automatically to 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just tag it as 'fork', on commit? That would be very visible, either prompting people to merge back and close the fork, or to rename the 'fork-' tag to meaningful branch name. From: Ron W Sent: Saturday, 18 April 2015 03:00 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two trunks?) Hello, Did you mean for your reply to go only to me? You did not CC the Fossil list. On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich s...@stef.rsmailto:s...@stef.rs wrote: From: Ron W Sent: Friday, 17 April 2015 11:04 To: Fossil SCM user's discussion Reply To: Fossil SCM user's discussion Subject: Re: [fossil-users] Two trunks? On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote: And a fork that ends in being merged is also no longer a fork. I disagree. While it might be the most common case, merging does not explicitly state any intent beyond the merge itself, even a full merge. After all, a merge doesn't automatically close a named branch. So why would a merge automatically make a fork not a fork? Closing it or making it the start of a new, named branch explicitly indicate an intent to remove fork status. ___ fossil-users mailing list fossil-users@lists.fossil-scm.orgmailto: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] terminology confusion
Thus said j. van den hoff on Fri, 17 Apr 2015 07:51:26 +0200: but if changing the terminology really is a seriously considered issue, than I cannot abstain from proposing shoot instead (which would open the theoretical possibility to indicate it as `SHOOT!' in the CLI timeline display -- which most of the time, would be correct, too ;-) If we're looking for a new term, then I propose ``aerial root'' because they're cool: http://commons.wikimedia.org/wiki/File:Aerial_roots_Banyan_Tree_Park.jpg Thanks, Andy -- TAI64 timestamp: 400055312be5 ___ 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] Can fossil be used to apply a diff patch?
On Apr 17, 2015, at 4:41 PM, to...@acm.org wrote: I was hoping fossil would be able to eat its own … diff patch(1) is the tool Larry Wall was famous for writing before he created Perl. It is one of those tools complex enough that there are no clones. There is a fork around licensing issues. The FSF took over maintenance of patch(1) around the turn of the millennium and GPL’d it, so the BSDs typically ship a version forked off from the last pre-GPL’d version. So, if Fossil were to get built-in patch(1) functionality, it would mean integrating something like this: https://svnweb.freebsd.org/base/head/usr.bin/patch/ That’s several thousand lines of tricky C code, all to replace a tool that is already on almost all non-Windows development boxes. A bit of tail wagging the dog, I think. Windows ships without a whole lot of tools. I suggest you treat this problem the same as you treat the compilers it doesn’t include, the decent text editors it doesn’t include, the decent web browser it doesn’t include… ;) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
