Re: [fossil-users] what determines the string length of sha1 display in the timeline?
On Thu, 12 Feb 2015 17:59:33 +0100, Warren Young w...@etr-usa.com wrote: On Feb 12, 2015, at 9:55 AM, j. van den hoff veedeeh...@googlemail.com wrote: making the probability threshold user settable instead seems less convenient since it is just a statistical measure and it is counterintuitive in the sense that it tells you something about chance of occurence rather than chance of hitting the collision. I think it depends on whether you’re the sort who prefers to play around with configurables or the sort who would prefer that the system tune itself. Any value for d 40 gives p 1.0. :) All my proposal does is make the p value explicit, instead of letting people tune d and hope they pick the correct value to achieve a reasonable p value. principally, it doesn't really matter how the objective I don't want to see collisions is translated into a single parameter I would say (p-value or prefix length d). but I would maintain that letting the user specify the p-value is indirect and misleading in the sense that, e.g. p = 0.1 suggests that I easily will get a collision in my interaction with fossil while all it tells is that in about 10% of repos of this size there will be somewhere a collision which -- as already explained -- I think is _not_ the relevant figure of merit. the collisions are harmless (below d=40 at least ;-)), so they very well can be there, I only do not want to encounter them and _that_ probability is lower than that p by a factor equal (roughly) to the number of checkins. incidentally, fossil itself might serve as an example: there currently are about 8e3 checkins and a single 7-digit collision which in fact has a probability to be there of about p=11% (so a bit of slightly bad luck that it already has happened ;-)) now you go and stumble about that collision by accident when inspecting files or performing diffs: probably no one ever has ... so your approach would suggest that setting p=0.11 would be a very bad idea for a repo the size of fossil but actually the collision (if it happens) will go unnoticed for a considerable time to come (and as everybody knows it is even quite rare to run into trouble with specifying length-4 prefixes to `-r' although there sure is a substantial number of collisions at that length). etc. your threshold p 1e-6 is simply to high for everyday use (even fossil itself would already need length 11 already to comply: but just let's wait until the first length-10 collision occurs around the year 20 (at current checkin rate) and then another couple of million years until someone tries to do a fossil cat of an affected arfifact. _then_ it's time to act. ;-) but anyway. it's probably something of a moot point. let's the devs decide it. as long as the hash prefix length then becomes consistent (and not execssively long) across all subcommands (that this is not the case currently is the only real problem...) I'm fine ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] what determines the string length of sha1 display in the timeline?
On Thu, Feb 12, 2015 at 2:55 PM, Warren Young w...@etr-usa.com wrote: I would still prefer that Fossil self-tune, however. While it is true that my formula doesn’t give intuitive p values, it is also true that you cannot pick sensible d values for a repository without knowing various characteristics about the repository. I think this problem is being over engineered. The key thing is that Fossil be consistent about how many characters it displays for a given hash. Currently, at least command is sometimes displaying a particular has with a different number of characters than at one other command is displaying the same hash. ___ 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] what determines the string length of sha1 display in the timeline?
On Feb 12, 2015, at 10:55 AM, j. van den hoff veedeeh...@googlemail.com wrote: p = 0.1 suggests that I easily will get a collision in my interaction with fossil while all it tells is that in about 10% of repos of this size there will be somewhere a collision Fair point. I would still prefer that Fossil self-tune, however. While it is true that my formula doesn’t give intuitive p values, it is also true that you cannot pick sensible d values for a repository without knowing various characteristics about the repository. I will think about this, and see if I can come up with a better formula, one which gives the desired result, which picks the number of digits that reduces the chances of a collision in daily use to some arbitrarily low value. I hope you will be out there trying to beat me to that superior formula. :) fossil itself might serve as an example: there currently are about 8e3 checkins and a single 7-digit collision My largest repository has 21 collisions at 7 digits. ___ 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] Alternative skin for the main Fossil website
Andy Bradford amb-fos...@bradfords.org writes: Thus said Richard Hipp on Wed, 11 Feb 2015 10:21:32 -0500: https://www.fossil-scm.org/skin2 Please let me know if you see any problems with the look of this alternative skin. Looks nice, except it has no background color. Perhaps this is intentional? Andy Thanks for your feedback. The background color lack is not intentionnal. I'll fix it quickly and look for a fix around the tab bug. Have a good day -- Étienne Deparis http://etienne.depar.is/ twitter: @milouse ___ 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] what determines the string length of sha1 display in the timeline?
On Thu, 12 Feb 2015 21:17:41 +0100, Ron W ronw.m...@gmail.com wrote: On Thu, Feb 12, 2015 at 2:55 PM, Warren Young w...@etr-usa.com wrote: I would still prefer that Fossil self-tune, however. While it is true that my formula doesn’t give intuitive p values, it is also true that you cannot pick sensible d values for a repository without knowing various characteristics about the repository. I think this problem is being over engineered. The key thing is that Fossil be consistent about how many characters it displays for a given hash. Currently, at least command is sometimes displaying a particular has with a different number of characters than at one other command is displaying the same hash. I agree that this is the real problem/inconsistency to solve. after that a fixed prefix of reasonable length (10 or 12?) will do. as I wrote to warren I'm, too, not convinced that some auto-tuning would be really beneficial. but of course the valid point remains that although length 10 will be good for almost everybody forever, it's not quite OK under certain circumstances such as in the netbsd example: although hitting the existing collisions in that repo is on average extremely unlikely it _can_ happen to someone accidentally interested in one of the affected revisions quickly. at which point it would be good if the user could just do `fossil set prefix-length 12' thus getting rid of the collisions and proceed. in short: an option to customize the length might still be useful. -- 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] hyperlink to the other wiki page in markdown
Hello, in fossil wiki format link to the other wiki like [OtherWikiName] works. Markdown link in the form of [OtherWikiName](OtherWikiName) doesn't. It seems that currently working markdown syntax is [OtherWikiName](wiki?name=OtherWikiName) Does it make sense to you to interpret more simple syntax in fossil as well? Peter ___ 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] what determines the string length of sha1 display in the timeline?
On 2/12/2015 1:30 PM, j. van den hoff wrote: it would be good if the user could just do `fossil set prefix-length 12' thus getting rid of the collisions and proceed. in short: an option to customize the length might still be useful. For small and young projects, a prefix of 10 feels long. I have repositories where I am essentially the only committer where a 6 character prefix is unambiguous. For that case too, having `set prefix-length` seems quite reasonable. It can default to 10, to minimize surprise to users. It should probably treat anything less than 4 as silly, however. I anticipate that the painful part of implementing this is the sweep through all the code that displays hashes to regularize the format. At the same time, removing the feature that extends the prefix to include a hex digit makes sense. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] Alternative skin for the main Fossil website
Great work on the new skin - about time! On 12 Feb 2015, at 2:21 am, Richard Hipp d...@sqlite.org wrote: […] Please let me know if you see any problems with the look of this alternative skin. 1) In the ‘Timeline’ page, the sub-menu buttons (“Older”, “Search” and “Unhide”) have no border by default, but have a border when hovered. When the border is drawn, it widens the buttons (by the thickness of the border), and makes all elements to the right shift a few pixels. It’s an annoying glitch that can be easily fixed by placing a white border on the buttons in their default state. That way, hovering over the buttons simply changes the colour of the border, and does not affect their width. Please note that this issue is present on all sub-menu buttons throughout the site - i.e., in the ‘Tickets’ page, the same thing happens with the “New” and “Reports” buttons. 2) In the ‘Timeline’ page, the date/time column needs to be wider: dates do not fit the width of the column, and wrap around to the next line, making it difficult to read at a glance. It may also help if the text of the dates was to be made (slightly) smaller. Looking forward to trying to develop a couple of custom skins myself! Kind regards, -- Igor Couto Sydney, Australia ___ 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] Alternative skin for the main Fossil website
Wed, 11 Feb 2015 16:29:21 +0100 j. van den hoff
veedeeh...@googlemail.com:
the box for specifying the max. number of displayed entries is
seriously clipped/not adjusted to textwidth within (see attachment if
this goes through...).
The input size= has been changed to =4 meanwhile. Maybe your browser
just cached something.
I'm not sure why it's a text input anyway. It loosens up the submenu
of course, but I can't picture anyone entering a custom number for
specific timeline lengths. Another dropdown with just 50|200|500|2000
might be more user-friendly.
also, moving/hoovering with the mouse over menu entries in this row
(newer, older, search unhide) leads to irritating
recomputation/adjustment of positions:
the entries jitter back and force due to the appearance of the gray
'selected' rectangle
That can be fixed with a minor preset for the non-hovered submenu:
.submenu a {
border: 1px solid transparent;
}
Uploaded a patched version here:
wget https://fossil.include-once.org/fossil-skins/cat/sanfrancisco.txt
___
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] Alternative skin for the main Fossil website
On Wed, Feb 11, 2015 at 5:21 PM, Richard Hipp d...@sqlite.org wrote: You can now access the Fossil self-hosting repository using the San Francisco Modern skin at: https://www.fossil-scm.org/skin2 Please let me know if you see any problems with the look of this alternative skin. When viewing the files using the tree-view (BTW, when did the flat view become the default again?) hovering on a tab does not open the bottom of it. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Alternative skin for the main Fossil website
On Thu, Feb 12, 2015 at 9:59 AM, Baruch Burstein bmburst...@gmail.com wrote: On Wed, Feb 11, 2015 at 5:21 PM, Richard Hipp d...@sqlite.org wrote: You can now access the Fossil self-hosting repository using the San Francisco Modern skin at: https://www.fossil-scm.org/skin2 Please let me know if you see any problems with the look of this alternative skin. When viewing the files using the tree-view (BTW, when did the flat view become the default again?) hovering on a tab does not open the bottom of it. Two more notes on the tree-view that are not specific to this skin but I noticed while playing with it: 1) If displaying only folders, if a folder has files, the last folder will have an extra line extending down from it 2) Why does clicking the root folder open/close the whole tree? Shouldn't it open/close only the root? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Alternative skin for the main Fossil website
On Thu, Feb 12, 2015 at 1:01 AM, Rich Neswold rich.nesw...@gmail.com wrote: IMO, though, I don't like the lines of text that close together, so I'd add a CSS directive like line-height: 125% to give a little spacing. But that's just me. Otherwise, it's a nice, contemporary look. It's not just you. For me line-height: 145% looks even better. And I would fix jumping tabs position when hovering with mouse. ___ 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] what determines the string length of sha1 display in the timeline?
On Feb 11, 2015, at 7:23 AM, Richard Hipp d...@sqlite.org wrote: On 2/11/15, j. van den hoff veedeeh...@googlemail.com wrote: whatever the reason, the netbsd example (a worst case scenario, really) would suggest to chose 12 instead of 10 as the future default length to avoid collisions these next some hundred years. Maybe the default prefix lengths should auto-adjust depending on the number of artifacts in the repository? That could work. If you rearrange the square approximation formula from the Wikipedia article to solve for m, then take the base-2 log of that to get bits, then divide by 4 to get bits per nibble (i.e. hex digits), you get: d = log2(n^2 / 2p) / 4 That is to say, it gives you the number of digits d required to achieve a given chance of collision p in a hash set size n. So for my 97,000 hash repo, we need 13 digits to approach p=1e-6. I suggest making the p value configurable, with a reasonable default. 1e-6 sounds good to me. ___ 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] what determines the string length of sha1 display in the timeline?
On Thu, 12 Feb 2015 17:21:50 +0100, Warren Young w...@etr-usa.com wrote: On Feb 11, 2015, at 7:23 AM, Richard Hipp d...@sqlite.org wrote: On 2/11/15, j. van den hoff veedeeh...@googlemail.com wrote: whatever the reason, the netbsd example (a worst case scenario, really) would suggest to chose 12 instead of 10 as the future default length to avoid collisions these next some hundred years. Maybe the default prefix lengths should auto-adjust depending on the number of artifacts in the repository? That could work. If you rearrange the square approximation formula from the Wikipedia article to solve for m, then take the base-2 log of that to get bits, then divide by 4 to get bits per nibble (i.e. hex digits), you get: d = log2(n^2 / 2p) / 4 That is to say, it gives you the number of digits d required to achieve a given chance of collision p in a hash set size n. So for my 97,000 hash repo, we need 13 digits to approach p=1e-6. I suggest making the p value configurable, with a reasonable default. 1e-6 sounds good to me. this would probably have to be done via `fossil set'. if it is made to be user-configurable at all (which I would welcome) it sounds simpler to me to just provide the user with the ability to change the number of digits, i.e. something like a new option `fossil set hash-prefix-length' so one can stay with the default of 10 until a real need for changing it occurs. what I mean: it makes more sense to me to just wait (using the 10 digits) until the first collision causes a hickup (which might be much later than creation of the collision in the repo: netbsd currently has 4 10 digits collisions -- but how often have they been triggered? probably never, since you would have to actually to pick one of those 8 artifacts from the 2e6 artifacts for the intended action (say a `cat')). if the user notices a collision, he can _then_ increment his setting by 1 or 2 digits or whatever he sees fit. making the probability threshold user settable instead seems less convenient since it is just a statistical measure and it is counterintuitive in the sense that it tells you something about chance of occurence rather than chance of hitting the collision. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] what determines the string length of sha1 display in the timeline?
On Feb 12, 2015, at 9:55 AM, j. van den hoff veedeeh...@googlemail.com wrote: making the probability threshold user settable instead seems less convenient since it is just a statistical measure and it is counterintuitive in the sense that it tells you something about chance of occurence rather than chance of hitting the collision. I think it depends on whether you’re the sort who prefers to play around with configurables or the sort who would prefer that the system tune itself. Any value for d 40 gives p 1.0. :) All my proposal does is make the p value explicit, instead of letting people tune d and hope they pick the correct value to achieve a reasonable p value. ___ 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] what determines the string length of sha1 display in the timeline?
On Feb 12, 2015, at 9:59 AM, Warren Young w...@etr-usa.com wrote: Any value for d 40 gives p 1.0. :) Ooops. I mean p 0. And yes, I realize that p never goes to 0, but since 40 digits puts the chance of collision into “heat death of the universe” territory, it’s close enough to 0 for my purposes. :) ___ 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] what determines the string length of sha1 display in the timeline?
On Feb 12, 2015, at 9:21 AM, Warren Young w...@etr-usa.com wrote: d = log2(n^2 / 2p) / 4 In C: double n = num_artifacts; double p = acceptable_probability_of_collision; assert(p 0.002); int d = ceil(log2((n * n) / (2 * p)) / 4.0); n needs to be a double because squaring 5 and 6 digit numbers gets you into scientific notation territory. We don’t want to require 64-bit ints to get the correct answer, and we need to do FP math with the result anyway. We should use ceil() instead of round() because we need to calculate the smallest number of digits that *exceeds* our requested probability of collision. Going back to my 97,000 hash repository example, we need 14 digits to do that, not 13. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
