Re: [fossil-users] Remove redundant shun links from doc page.
On Mon, Jun 22, 2015 at 11:26 AM, sky5w...@gmail.com wrote: Ok??? Kinda annoying since I clicked all 4 to see which is more relevant only to see they are identical. Not sure why this is a preferred output? If the auto-generate stores to a map with the link as a key, then only 1 identical key will survive. Otherwise, it requires a multi-pass cleanup. I can appreciate what you're saying, but it is quite common: https://en.wikipedia.org/wiki/Key_Word_in_Context On Mon, Jun 22, 2015 at 1:17 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jun 22, 2015 at 7:15 PM, sky5w...@gmail.com wrote: This link is referenced 4 times: http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki Here: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html lots of stuff is duplicated on that page - those links are automatically generated using various permutations of the link's name. i.e. it's by design. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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
Re: [fossil-users] Remove redundant shun links from doc page.
On Mon, Jun 22, 2015 at 7:15 PM, sky5w...@gmail.com wrote: This link is referenced 4 times: http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki Here: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html lots of stuff is duplicated on that page - those links are automatically generated using various permutations of the link's name. i.e. it's by design. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Remove redundant shun links from doc page.
Ok??? Kinda annoying since I clicked all 4 to see which is more relevant only to see they are identical. Not sure why this is a preferred output? If the auto-generate stores to a map with the link as a key, then only 1 identical key will survive. Otherwise, it requires a multi-pass cleanup. On Mon, Jun 22, 2015 at 1:17 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jun 22, 2015 at 7:15 PM, sky5w...@gmail.com wrote: This link is referenced 4 times: http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki Here: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html lots of stuff is duplicated on that page - those links are automatically generated using various permutations of the link's name. i.e. it's by design. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Remove redundant shun links from doc page.
On Mon, Jun 22, 2015 at 7:26 PM, sky5w...@gmail.com wrote: Ok??? Kinda annoying since I clicked all 4 to see which is more relevant only to see they are identical. Not sure why this is a preferred output? If the auto-generate stores to a map with the link as a key, then only 1 identical key will survive. Otherwise, it requires a multi-pass cleanup. Try searching that page for delta for two other sets of dupes. It's intended (AFAIK) to get users to the things they're looking for based on various formulations (since people think differently). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Remove redundant shun links from doc page.
This link is referenced 4 times: http://www.fossil-scm.org/index.html/doc/trunk/www/shunning.wiki Here: http://www.fossil-scm.org/index.html/doc/trunk/www/permutedindex.html Content From Fossil — Shunning: Deleting Deleting Content From Fossil — Shunning: From Fossil — Shunning: Deleting Content Shunning: Deleting Content From Fossil My vote is keep only 1: Shunning - Deleting Content From Fossil Thanks for Fossil! ___ 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] Remove redundant shun links from doc page.
Hello, On 22 June 2015 at 20:11, Ross Berteig r...@cheshireeng.com wrote: On 6/22/2015 10:46 AM, sky5w...@gmail.com wrote: I agree we all think differently, but the output should collate the descriptions while keeping only a single common link. The difference with the wiki 'keyword in context' is I can see the duplication. The auto doc page infers many unique links. The whole point of a permuted index is to provide an alphabetical list of keywords, shown along with some context, and references (links) to where they appear. ... ok, I tried to do this earlier with a bit of effort, but my TCL-foo is too weak: how about displaying the permuted index (if that must be - I don't see the whole point of it, since there is a browser 'search' function anyway, but hey :-), but display canonical links in bold. The section header could then be something like Permuted index, (canonical titles displayed in bold). Is that an idea? Michai ___ 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] DB corruption and error msg string mis-handling.
W/ latest fossil from tip of [trunk], a pull now looks roughly like this (note, no reported errors or warnings, no looping like before, but still not actually working properly): kamloops$ fossil pull --verbose Pull from http://netbsd.sonnenberger.org Bytes Cards Artifacts Deltas Sent:9546202 0 0 Received:1412 31 0 0 Pull done, sent: 5076 received: 1031 ip: 135.28.13.11 kamloops$ fossil timel === 2015-06-04 === 16:11:48 [84f521116f] *CURRENT* Whitespace and macro fixes. (user: wiz tags: trunk) 16:01:09 [ea0e467f7e] Document the options as a list instead of embedded text. (user: christos tags: trunk) 09:45:43 [53ab9b8bbe] Ticket 822. (user: msaitoh tags: netbsd-7) 09:44:57 [04f6adcaf6] Pull up following revision(s) (requested by hsuenaga in ticket #822): sys/net/if_gif.c: revision 1.85 sys/net/if_gif.c: revision 1.86 Obtain softnet_lock before entering IP networking stack from gif software interrupt. Include sys/socketvar.h for softnet_lock. (user: msaitoh tags: netbsd-7) 09:20:12 [e24f89baf3] Whitespace fixes. (user: wiz tags: trunk) 09:19:59 [6c6ebdc911] Pull out route lookups from L2 output routines Route lookups for routes of RTF_GATEWAY were done in L2 output routines such as ether_output, but they should be done in L3 i.e., before L2 output routines. This change places the lookups between L3 output routines (say ip_output) and the L2 output routines. The change is based on dyoung's patch submitted in the thread: https://mail- index.netbsd.org/tech-net/2013/02/01/msg003847.html You can find out detailed investigations by dyoung about the issue in there. Note that the change introduces a workaround for MPLS. ether_output knew that it needs to fill the ethertype of a frame as MPLS, based on a tag of an original route (rtentry), but now we don't pass it to ehter_output. So we have to tell that in another way. We use mtag to do so for now, which introduces some overhead. We should fix it somehow in the future. Discussed on tech-kern and tech-net. (user: ozaki-r tags: trunk) [...] On 6/19/15, bch brad.har...@gmail.com wrote: include fossil-users@ ... -- Forwarded message -- From: bch brad.har...@gmail.com Date: Fri, 19 Jun 2015 12:05:13 -0700 Subject: Re: [fossil-users] DB corruption and error msg string mis-handling. To: Andy Bradford amb-fos...@bradfords.org Hi. I got around to reviewing this, and found a couple interesting things: 1) some of the reported 0-byte entries are now gone 2) Here is report from the single remaining offender: rid: size calculated_size_of_blob, reported_uuid, calculated_sha1 == 1355: 0 calculated_realsize(12), reported_uuid(da39a3ee5e6b4b0d3255bfef95601890afd80709), calcuated_sha(b844a4567c46013e52dc15a63bda87b7160266ef) On 6/11/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said bch on Mon, 08 Jun 2015 15:31:31 -0700: rid: size == What are some of the SHA1 hashes for these RIDs? Thanks, Andy -- TAI64 timestamp: 40005579f382 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
