Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two trunks?)
On Wed, Apr 22, 2015 at 9:50 PM, Andy Bradford amb-fos...@bradfords.org wrote: Also, it only warns if it encounters a fork that has not previously been seen Only for sync, or does it also only report new forks when fossil forks is run? In my opinion, fossil forks should report all forks, even previously detected ones. ___ 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?)
Thus said Ron W on Thu, 23 Apr 2015 13:13:12 -0400: Only for sync, or does it also only report new forks when fossil forks is run? In my opinion, fossil forks should report all forks, even previously detected ones. Yes, only in the context of a sync. E.g. someone makes a commit, you are working offline and also make a commit against the same node in the timeline. This creates a ``sleeper'' fork. When you go back online and sync your content, you will receive a warning that a fork has occurred. It also suggests you use ``fossil forks'' to find it. However, because you now have the fork, you will not be notified again during a sync about it. Andy -- TAI64 timestamp: 400055392cdb ___ 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?)
2015-04-23 3:50 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: I've altered the change and now it will only check at the end of the complete sync. Also, it only warns if it encounters a fork that has not previously been seen (ignoring any additional checkins on a fork unless they also are new forks). I think this will minimize fork warning fatigue that is an outstanding concern. Good work, I like it! +1 for merging it to trunk. I don't think the problem is with ``fossil forks'' however, because after running ``fossil rebuild'' on z.fossil, ``fossil forks'' correctly reports that there are no forks. So it seems that for whatever reason, running ``fossil pull'' the way we are for the test results in not all nodes being properly designated in the tables. This behavior exists in trunk as well. $ ./fossil forks -R z.fossil (1) 2015-02-24 06:40:00 [8c3e6404b0] Let -x imply --emptydirs and --dotfiles (user: jan.nijtmans tags: cleanX-no-clean-glob) (2) 2013-06-21 09:27:19 [dfb47a2a2e] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (3) 2013-06-19 07:14:13 [cbf9660369] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (4) 2013-04-03 07:36:05 [6159a7f281] rebase (user: jan.nijtmans tags: clean-with-ignore) (5) 2013-04-02 09:31:26 [bdd9790484] merge trunk (user: jan.nijtmans tags: clean-with-ignore) Yes, this must be a bug somewhere in the pull handling, which is caused by the rebase action I did (as experiment). Have a look at this commit: http://fossil-scm.org/index.html/timeline?f=2e545d58 You will see that a new clean-with-ignore branch was created from trunk, the old content of clean-with-ignore being merged in. Even though effectively the branch didn't change, apparently the pull concluded that 2e545d58 is a leaf, while fossil rebuild correctly decides it isn't. Of course, I could explicitly add a close tag here as workaround, but for the sake of bug reproducibility I'll leave it like this ;-) Thanks! Good catch! Pleading guilty! However, as you correctly stated, this is unrelated to the recent fork handling improvements, so still good-to-go from me. Thanks! 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] How about renaming a fork to fork-*? (Was: Two trunks?)
Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200: Explanation: the current code in sync-forkwarn doesn't do the fork-check at the end of the sync, it does it at the end of each round-trip. I've altered the change and now it will only check at the end of the complete sync. Also, it only warns if it encounters a fork that has not previously been seen (ignoring any additional checkins on a fork unless they also are new forks). I think this will minimize fork warning fatigue that is an outstanding concern. http://www.fossil-scm.org/index.html/info/64b221aacf136594 By the way, I'm not sure if this is a bug (because we're not really cloning as we normally would), but while testing using your method of creating an empty repository, altering the project-code and pulling the Fossil repository, after the pull is complete, while no warnings are issued, ``fossil forks'' actually reports forks. The difference in time for such a big sync remains negligible, perhaps even improved results from when you tested (I suspect the faster time for the [64b221aacf] below was due to network causes): $ ./fossil version This is fossil version 1.32 [64b221aacf] 2015-04-23 00:35:34 UTC $ ./fossil new z.fossil ... $ printf UPDATE config SET value = 'CE59BB9F186226D80E49D1FA2DB29F935CCA0333' WHERE name = 'project-code';\nDELETE FROM blob;\nDELETE FROM event;\nDELETE FROM unclustered;\nDELETE FROM tagxref;\nDELETE FROM rcvfrom;\nDELETE FROM leaf;\n | ./fossil sql -R z.fossil $ time ./fossil pull -R z.fossil http://www3.fossil-scm.org/site.cgi Round-trips: 270 Artifacts sent: 0 received: 30708 Pull done, sent: 851133 received: 19754467 ip: 72.52.64.58 real3m54.302s user0m49.110s sys 0m3.743s $ fossil version This is fossil version 1.32 [92be5246f8] 2015-04-20 07:20:05 UTC $ fossil new z.fossil ... $ printf UPDATE config SET value = 'CE59BB9F186226D80E49D1FA2DB29F935CCA0333' WHERE name = 'project-code';\nDELETE FROM blob;\nDELETE FROM event;\nDELETE FROM unclustered;\nDELETE FROM tagxref;\nDELETE FROM rcvfrom;\nDELETE FROM leaf;\n | fossil sql -R z.fossil $ time fossil pull -R z.fossil http://www3.fossil-scm.org/site.cgi Round-trips: 270 Artifacts sent: 0 received: 30708 Pull done, sent: 851139 received: 19754477 ip: 72.52.64.58 real4m2.294s user0m40.539s sys 0m3.552s I don't think the problem is with ``fossil forks'' however, because after running ``fossil rebuild'' on z.fossil, ``fossil forks'' correctly reports that there are no forks. So it seems that for whatever reason, running ``fossil pull'' the way we are for the test results in not all nodes being properly designated in the tables. This behavior exists in trunk as well. $ ./fossil forks -R z.fossil (1) 2015-02-24 06:40:00 [8c3e6404b0] Let -x imply --emptydirs and --dotfiles (user: jan.nijtmans tags: cleanX-no-clean-glob) (2) 2013-06-21 09:27:19 [dfb47a2a2e] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (3) 2013-06-19 07:14:13 [cbf9660369] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (4) 2013-04-03 07:36:05 [6159a7f281] rebase (user: jan.nijtmans tags: clean-with-ignore) (5) 2013-04-02 09:31:26 [bdd9790484] merge trunk (user: jan.nijtmans tags: clean-with-ignore) $ ./fossil rebuild z.fossil 100.0% complete... $ ./fossil forks -R z.fossil $ Andy -- TAI64 timestamp: 400055385013 ___ 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?)
Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200: It seems it's not wise at this moment to merge sync-forkwarn to trunk since false warnings here may be more confusing than that they help :-( You're right. I thought I had moved it sufficiently to the end of the client_sync, but apparently db_end_transaction is also called at the end of each round-trip. So it is definitely not ready. Thanks for checking this, Andy -- TAI64 timestamp: 400055355bba ___ 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?)
2015-04-19 2:06 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: The only time that fork detection makes sense (if at all) is *after* a complete sync in the client. Just repeated my earlier experiment using sync-forkwarn branch, and got: $ time ./fossil pull -R z.fossil http://www.fossil-scm.org/index.html Round-trips: 209 Artifacts sent: 0 received: 17734 Pull done, sent: 761275 received: 10502627 ip: 67.18.92.124 * WARNING: a fork has occurred * use fossil forks for more details. Hey, the self-hosting fossil repository doesn't contain forks any more, how is this possible? Explanation: the current code in sync-forkwarn doesn't do the fork-check at the end of the sync, it does it at the end of each round-trip. Since there were some forks created long ago which were only recently closed, this can result in a false warning: Maybe the artifacts in a round-trip create a fork, but this fork is resolved in some future round-trip which is still part of the same sync operation. It seems it's not wise at this moment to merge sync-forkwarn to trunk since false warnings here may be more confusing than that they help :-( 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] How about renaming a fork to fork-*? (Was: Two trunks?)
On 4/18/15, Steve Stefanovich s...@stef.rs wrote: 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? When the artifacts that comprise a fork are received, the server has no way of knowing that new artifacts that resolve the fork (either by merging or by moving it onto a branch) will not be received within the next few milliseconds. Hence, what you suggest could result in strange and mysterious changes occurring to the check-in topologies during a push. Very undesirable, I think. -- 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] How about renaming a fork to fork-*? (Was: Two trunks?)
Thus said Richard Hipp on Sat, 18 Apr 2015 07:50:42 -0400: When the artifacts that comprise a fork are received, the server has no way of knowing that new artifacts that resolve the fork (either by merging or by moving it onto a branch) will not be received within the next few milliseconds. I came to this realization as I was working on the sync-forkwarn branch. I abandoned the thought of having the server try to detect a fork for this very reason. It doesn't have all the necessary information to make such a decision, and indeed, the resolution of the fork may actually arrive in the next round-trip. So I removed that functionality. The only time that fork detection makes sense (if at all) is *after* a complete sync in the client. Andy -- TAI64 timestamp: 40005532f19c ___ 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?)
Let me rephrase - maybe I was a bit ambiguous what I meant. On pull/update, when fork happens locally, the code would automatically do what currently happens when someone edits the check-in and puts it on a new branch. So on a local repo/check-out, developer sees he's now on (latest leaf of) fork-trunk branch, instead of thinking he's on a trunk while in reality he's on a fork of the trunk which is named the same. Dev merges back to trunk and commits, or edits the beginning of the fork (if he has a sequence of check-ins) to a branch name he likes in case he wants to keep it as a branch, and pushes. So what would end up on the server that is strange or mysterious on such push apart from an extra tag, fork-trunk? What am I missing? Original Message From: Richard Hipp Sent: Saturday, 18 April 2015 21:50 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?) On 4/18/15, Steve Stefanovich s...@stef.rs wrote: 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? When the artifacts that comprise a fork are received, the server has no way of knowing that new artifacts that resolve the fork (either by merging or by moving it onto a branch) will not be received within the next few milliseconds. Hence, what you suggest could result in strange and mysterious changes occurring to the check-in topologies during a push. Very undesirable, I think. -- 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] 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
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] How about renaming a fork to fork-*? (Was: Two trunks?)
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.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
