[fossil-users] Partial commit of merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [fossil commit] refuses to commit only selected files when a [fossil merge] was done. This makes sense, except the test for partial commit is a bit too simplistic. Rather than requiring that every modified file be part of the commit, [fossil commit] should require only the files modified *by [fossil merge]* be part of the commit. In other words, it should only be necessary to commit what [fossil changes] labels UPDATED_BY_MERGE. If I have files in my checkout that were changed for other reasons, I shouldn't be forced to stash, commit, or revert them just because I'm doing a merge. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyIhCAAoJELtYwrrr47Y4AWwH/jxmlXGIEgvyt9K7fQDSdJEC Z4qBRZbinWx746TAPRNnFl0EkOCO8gAYwTuBSOF9NJ4iUsTy3p4yV3UU0F92l72J 6h7HoxR0wyT+tOaA4bEjJB/M5wvrVE8HloWSM/jFCxVdz7vUUCZTM8gckX/P2w+R oEKOl1//qVSxpru90fHlkzeFn3m7af5Y9oGrrzHXfIOFgjLbP/8I75w25Acljde5 RcK4AdVHaHZESwsuvP9ELpF/j00jZzKFaoOw1vSGfy0LwbawKoatIkQAcL2AxqOz luqTDPD7421QKySPafPbHOg8Fys1TWhE9zjACZLBttf/dYxlt/7VQWEoclgLpbY= =PEvh -END PGP SIGNATURE- ___ 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] 'open --nested', quick poll
On 7/22/2014 9:38 AM, Michai Ramakers wrote: I was wondering how many of you use 'open --nested' to have nested workdirs? Tcl nests whatever repositories you want checked out into subdirectories of pkgs. Each nested repository is expected to further nest the Tclconfig repository (itcl and thread do this), though they can instead have their own tclconfig directory (I think sqlite does this, though I see it in its autoconf/tea subdirectory). -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Error: bad command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I attempted to push via Citrix's \\client mechanism, but got this failure: H:\fossil fossil push -R repository.fossil -once file:client/c$/users/andy/desktop/work/fossil/repository.fossil Round-trips: 5 Artifacts sent: 4 received: 0 Error: bad command: j~~lqL\ Round-trips: 5 Artifacts sent: 4 received: 0 *** time skew *** server is slow by 2.5 minutes Push finished with 46313306 bytes sent, 2728 bytes received H:\fossil fossil push -R repository.fossil -once file:client/c$/users/andy/desktop/work/fossil/repository.fossil Round-trips: 2 Artifacts sent: 1 received: 0 Error: bad command: j~~lqL\ Round-trips: 2 Artifacts sent: 1 received: 0 Push finished with 43031255 bytes sent, 980 bytes received H:\fossil fossil version This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC This has worked for me many times in the past, though slowly and clumsily. Any ideas what could be going on? Sadly, I'm not in a position to debug anything. Repeated attempts to push didn't help, nor did making more changes upstream, pulling them in, and pushing again. Rebuild didn't help. I tried deconstructing, but I ran out of quota. How stuck am I? At this point the only thing I can think to do is shun the large files I can do without, then reconstruct a much smaller repository. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT7UYDAAoJELtYwrrr47Y4BaEH/34jb/mpcJVGU8QoUu9OuKhc jpYVtW5h5FL2OqjOSfY7oM4p8lbkpDjoLOLNCX6WnnVz203qmSpB4GHXWzfYRdJ7 4Swr02CAZiLxws2vqbwyVL/y6f/T/0omLKIpPDvRjsXTxDSEYDKYq6GI4pRFOBxw LaEgDiMlT6MZ4u2k7ETQBgZvqdsJSpSpjEwkq4EEYaXSDHbrU6FrkAFyrffQiT8w t+M1seWyALLSNQkfOwEvxCOxxVsBp3viG7rHTmmUkiaxjeYbYwnq0Z5MHP7/QrrQ BJxRRqK9lPV4ytUs0btxvo8/NpUY+yyvylbPQGk1RxfYZDtIS4LynKwTaf8JJL8= =T7ZA -END PGP SIGNATURE- ___ 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] Error: bad command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/2014 6:28 PM, Andy Goth wrote: H:\fossil fossil push -R repository.fossil -once file:client/c$/users/andy/desktop/work/fossil/repository.fossil Round-trips: 5 Artifacts sent: 4 received: 0 Error: bad command: j~~lqL\ At this point the only thing I can think to do is shun the large files I can do without, then reconstruct a much smaller repository. Shunning corrected (dodged) the issue. I'll just keep those larger files outside the repository. They're high-resolution photos and videos, aren't going to be changing anyway, and are not referenced by anything else in the repository. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT7UnjAAoJELtYwrrr47Y4SfMIAJ5gFZVgKB5FK6haeMSRCJ8l eDmYdejkLcRB76Ri0GqFKYQMnWKvsz6MAP5Vie2SHKbBbFKbC+InlN/9QNmR5xZ8 0YPSbzWGheUH1UySftS4oPh2Z3ht7KQxS7NdvKf9P/RH5TFZpr387q7luETLljUg 4pbi0rdbd3/YztJbIgIhcTXyRNMeTV9+TewWP7Fqt3IaIm7zBMwy8frThEhMfoj9 Eihk9hbhtL4GfOLHQnmudCO3eok5lqrlHv5uRj1QiwFsZNB/AaQFrflE8yQnNxSV T/08/E2ManYv5njASL51Pa9M0nFYpRVr+Eh7KsDC4vRr4qAzuwuhiih1gOdd0ZU= =OQRX -END PGP SIGNATURE- ___ 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] Error: bad command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/2014 8:56 PM, Andy Bradford wrote: Thus said Andy Goth on Thu, 14 Aug 2014 18:28:03 -0500: At this point the only thing I can think to do is shun the large files I can do without, then reconstruct a much smaller repository. So is it because of the big files that this is happening? Just how big are these files? One up to forty megabytes. I think the overall repository got between fifty and sixty. The shuns cut it down to less than five. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT7W1hAAoJELtYwrrr47Y4/rkIAKCVNyb/PC2+KGrYg27Krv8k BWMalZip6wbz1G0al4//soNvpB8prUst2FSEfyobCiP/jSVmEqM7XsjI45Oaj73Y 7/+33utRXEp+CNSsn/a6iboZH62a6BV8qWLocmxArN6p4z+QQq+ciGNpgi56wR27 VB/fAqg49C/pxvb/LfhThxPAJqsq2+J1w0lECYI4g9gQPp7CMG8Z5jUvOe6Q5GzH 5wPa4zx//BuYiGQt/R1FW9EXYC0okeOJjVkGZ6u/udx7N8qeOoiNJskcGd+Wc6ug 3AM0mMx9XThcyz8xuZWov8S9lgEx7IC1lW9Hj+ii6eV/Xm0BxwcwpNM/fpiGmDk= =aAHZ -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm working on a project where the first version given to me was far from the first version that existed. Having nothing else to go on, I used it as the initial check-in of my new Fossil repository. Now I have been given a few older versions. What's the best way to go about putting them into the repository? I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I could also make a whole new repository with everything committed in the right order, but this is error-prone and, frankly, too OCD for my liking. By the way, --date-override is documented for some commands (e.g. tag) but not for commit. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAiiWAAoJELtYwrrr47Y4jesIAOILfX6anlRgkbneiISmjKQx xuQgcmsqpof14dGsbCq8LAWaDsKVOMWw0pDefLoJBHVtYpfR5cR7cNkjLGA4WFNl HKO8FqYHYjdPto16BMMKFK7paeGtuAernVZvyfsZRtBxAIg+LwdPXwivxBzSkMO4 RIzGiK86AXtbSCo7fnRyAunPzyFDXxzOeujrgFJfPrxny8WemRh3rVSHjSC1fh33 FwraAX1wHbVGA026iauOb3YSvunPy6OdsDGZWtqK9S65ZyQQjLJIrL9tWNdufjvF XSt94qygfLSC02WkJ4vlWWKZLQtyXlP7To08m/XkQFg46yfDmYSEZm3G1b1H+FE= =7rTV -END PGP SIGNATURE- ___ 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] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2014 2:40 PM, Andy Goth wrote: Now I have been given a few older versions. What's the best way to go about putting them into the repository? I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I cloned my repository and did the above as a test just to see how bad it comes out. Well, it's pretty bad. Not only is the timeline bizarre, the default diffs are unhelpful too. Diffs are typically against the predecessor version, but in this situation, Fossil's concept of predecessor doesn't match the naïve user expectation. Surprise notwithstanding, this is correct behavior in face of the time paradox. I think my best course of action is to not try to put the old code into the repository unless I am given a more complete archive of historical versions, at which time it might be worthwhile to rebuild the repository with everything put in the right sequence. Of course this blows away all the artifact IDs, but that would be acceptable at this stage. Let's say I do this, using the oldest known version as the initial commit, and everything seems good for a while. But then someone finds an in-between version thought to have been lost. I would update to its predecessor version then check it in with the date override, either allowing the fork or putting it on an branch. The timeline would look mostly good, but only because the predecessor version already existed. Diffs surrounding the newfound would have to be done with explicitly selected from and to versions, but that's a small price to pay for not having to rebuild the repository and trash the artifact IDs. Then a version older than the previously oldest known version is found. Now we're in trouble again. Maybe I could have prevented that last problem by making the initial empty check-in be dated before the project was known to have started, so there would never be anything older than it. Thoughts? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAi4UAAoJELtYwrrr47Y4J8MIAMbIomO0T3d/lNiClwMi7Ph1 uoeWBPmmz1hd8cQlgT0uS/u6bhYQkOSqeDRM3kWPJCV9iDeRAdQ2wfJjT2/iv3ez OWQGDQcveIL36yBVzBAzGMmTrLKxtSxSZ5gjHzi6t7hn3bALz+6JySbDiHqUhNui 0QlvLz1+I0JyUepWw4OXzX6FzTUY4ldgZWz88N6DojX89zTdnwJo4sgFj8tV 1iL+xIwoQVDzoB+UMPc4uLGuMTSBDU5rzQS9ohvliniadoRPeI52BanLnm3zNP36 pp1BI3cKKynJH1DPP7ybTD0Y3XM6HqQUiO83JCsZSBAtn44zKJ86Qwpb/zzpIog= =g08t -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Shunning and assertion failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm continuing to experiment with putting old versions into the repository. This necessarily meant numerous false starts and failures (it's a fool's errand, really), which in turn mean shunning and trying again (compounding the mistake). I was able to get my repository into a sorry state where this happens: $ f up version-4.31 fossil: ./src/bag.c:146: bag_find: Assertion `e0' failed. Aborted Seems like this happens when I try to update to any version identified by a tag, even trunk and tip. Updating to a timestamp also fails. Going to rebuild and keep trying, but I thought I should report the assert failure even if the path to it was long and naughty. By the way, $ f version This is fossil version 1.30 [e4bc6f12ea] 2014-08-30 09:03:26 UTC - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUApLTAAoJELtYwrrr47Y4+u4IAMmJv4dhe4dY++PoVKaZM5Nl Tz5gdmude2FdqYkasYsaD9qfi6mG4R3ztda7bHn2hy5zfpm0g2NE0pLfRr29lach WomeMTUAf1I5m/eaAcZmlvWGO1H1U4x1fMwGycpoojddJJTOv6HdY4vLCKolV0fA Aa+rUhsnx/9wLrpkj+hpwbGdPx4gXIKB+Xe3tA0/3f+FugyYTUSPKxnXXKAl0rQ0 eLTtGoPNMeFX5VNHM6xXdR5CSV1ksX1e7TaGNXikbhlRKbBwlbQdnM6mzUrxZFVU WMtHxuzwNQVCj49VtqabbKOuxoOpPYGPMjczO0x/FYIEFmfaF2dwfhfgFNZ5TxA= =RJYc -END PGP SIGNATURE- ___ 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] Shunning and assertion failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2014 10:13 PM, Andy Goth wrote: $ f up version-4.31 fossil: ./src/bag.c:146: bag_find: Assertion `e0' failed. Aborted Going to rebuild and keep trying Also I should mention that the assert failure goes away following rebuild. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUApNfAAoJELtYwrrr47Y46LkH/jzxZ8gBz5JXyW1GQU/XsvL3 +kyoFRJyYP/KH2LkNJNQFmf00thSj1RFzzsj9BKi9v7+BBAP1nIOW+jcDNNU9hSs Bykv4QrdTqHNhyyiQSUI7rz/HfJWjRp5r+SAae5xnC8uvtu6AjTDxezt637c/pQc +6hQ6YbP7+Hdu9yILCUa6TiVxzlMhUDvTu3dkVusD/02s9u5UDk+MecRDGvASrCw 5sKUnuv85rZrv+fqKL/W1VMkOQmXDZjctuUTJjTvTgjA2GG42OgUFOkrUw2WKmHU B8FWgF3R5UgCb9XgC2Oaxh7n+Ao4smLMqWSgPO+a/Dj5D3xCyOssC92J955yMfE= =aKe4 -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Comparing unified and side-by-side diffs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have some code here (can't share it with you, sorry) where I unified
and side-by-side diffs show up significantly differently. Ignoring
whitespace only changes what parts of the lines are highlighted, so I
won't be discussing it further.
Here's what the original code looks like:
// Comment at line start
if(cond cond cond)
{
stuff;
}
// Comment at line start
if(cond cond cond)
{
stuff;
}
And the new:
// Comment at line start
if (cond
cond
cond) {
stuff;
}
// Comment at line start
if (cond
cond
cond) {
stuff;
}
The side-by-side diffs look like this:
// Comment at line start// Comment at line start
if(cond cond cond) | if (cond
{
cond
cond) {
stuff; stuff;
} }
// Comment at line start
if(cond cond cond)
{ |
// Comment at line start
if (cond
cond
cond) {
stuff; stuff;
} }
I find this quite odd.
The algorithm gets off to a good start, treating the first if line as a
change. But then it deletes the { line and inserts the remainder of
the conditionals. Perhaps this is because { alone isn't enough
context for it to decide that the third line is a change rather than a
new line. I don't mind that part so much.
What really confuses me is the handling of the blank line that is
inserted before the second comment. Rather than just insert a blank
line, the side-by-side diff deletes the comment and the if, then
replaces the { line with the blank, then reinserts the comment (even
though it's completely unchanged from the original) followed by the new
version of the if.
Wouldn't it be more efficient to say the following? Due to having more
change lines than inserts and deletes, this presentation uses thirteen
lines whereas the above uses sixteen.
// Comment at line start// Comment at line start
if(cond cond cond) | if (cond
cond
{ | cond) {
stuff; stuff;
} }
// Comment at line start
if(cond cond cond) | if (cond
cond
{ | cond) {
stuff; stuff;
} }
Ah well. Meanwhile, the unified diff looks perfectly good:
// Comment at line start
- -if(cond cond cond)
- -{
+if (cond
+ cond
+ cond) {
stuff;
}
+
// Comment at line start
- -if(cond cond cond)
- -{
+if (cond
+ cond
+ cond) {
stuff;
}
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUA/dUAAoJELtYwrrr47Y4KAYH/j+OouBBwNyMokfTwLfNZWWy
2aRoUMYIo7I/NsL5tJgufmMfan1U/u8frmukRyuumZ+xwNtRyQGuTpd5jpNfHzgd
uVvYk6U21Hq+zvVGlRw3HKSFg2RmzJmS9An8d2MIq4V+ZUQs22SCwtPPYtqJ+A25
QMmfaWOVIgmyRDx8u2H+EDLbP0TCjtZ1XeJJyWwTETFUSR0+s2HjNe/Y2S0enc62
4tYbkEjVYOxqAbmeb+TdDgYZkg93pOpPxATrGkX+yNIJgEBFB0+LMhjf/mxgIpyG
U9a4AEYgK5E25v5/R9YnNJdzyYMZFdUoOv+fSO+CtDf4Yt1kHJfn82+Wil5gzjg=
=jpuE
-END PGP SIGNATURE-
___
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] Comparing unified and side-by-side diffs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/31/2014 11:34 PM, Andy Goth wrote:
Ignoring whitespace only changes what parts of the lines are
highlighted, so I won't be discussing it further.
Correction: it actually does make a difference. The diff I shared in
the previous email was made with ignore whitespace turned on. With
ignore whitespace turned off, every changed line is a delete or
insert, except for the { which is modified to be a blank line.
- --
Andy Goth | andrew.m.goth/at/gmail/dot/com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUA/kUAAoJELtYwrrr47Y4yEYH/Ag6NdKaZ1Xnkw+/SPauZ8Ab
IUlhkzcER1wRbPRV5l3GgiX3d+gAOHPRZK3xm6XD2v/FQlXpmyLqvcAvnP6URd+7
p9vKaOyQajfkcvuXA8wyN9xvEyb/IVDc0hXLjiPBLfsy1zW9osc7p2lF7nOuFVuG
zsGLm9yHejkOSiTEZOlQuAUlKsbAtpxOP6GTAEqMD1vtlcy0FmAQOucl1uGYLALZ
DfUpouHpw4jAHn6WSqrnIjGWShjy3XI6CAwMwY+5kRl9EyLdnmW4SarvuEP/2UYV
KBiRY9dH6TRfkGgaD+PH1LxzT3uA2kioFmYZ/4BgUXpHb7UbxTptRAGf/3EuSbE=
=4e+a
-END PGP SIGNATURE-
___
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] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/1/2014 3:20 AM, Eduardo Morras wrote: Can you try to do it backwards? (don't know if backwards is the rigth word). Create a new repository, import the older source files, pull from your repository. Don't sync or your repository will become fluffed. No, as Richard pointed out, there is no way to change the predecessor of existing manifests. Predecessor artifact IDs are stored directly in the manifest, so they contribute to the manifest's artifact ID, which in turn is the predecessor artifact ID of subsequent manifests. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUBKN2AAoJELtYwrrr47Y4xMUIALeja1VV97mJV42eiugtfR9U ZFroPRgZ+Fvu06/UCrAeC+0vJUD49UwEO3k9leOHXXbf1ZZb9ZvLYpDHoevwGa1Z ALnCzq1cQF1+jRrK+UH+xxFEbub32VAphRICt4W3F+PJWiyyZRFHg6RXSocL1B+R s2l3MJaR5o7QscPck3jCUi6FpVUOq+lMA1HWJs74a+A5C/vScfzE48eem00HFn6F a2DkCFYS7gHZt4SOgPVcKo41r0xuaMthX0Im4K2Q5KUOL0Nfg8A81HVOXbDRiD5G Mi/aJNKH84yx/g4gGz+LzJaTOan70ffW2pxM8IIqfG+E/s791FGta0WtiDV5FZU= =5dIR -END PGP SIGNATURE- ___ 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] versioning system suggestions for a musician?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/2014 1:45 PM, Ron W wrote: Hello, Andy. Haha, actually I just forwarded the original post on behalf of Inverse Phase who is not subscribed. I forwarded your reply because you Cc:'ed me rather than him. Replies in this thread need to be Cc:'ed to: Inverse Phase inverseph...@gmail.com - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKbVzAAoJELtYwrrr47Y4HgkH+gJCX/tJOsPIxCC1xWRMyRTe sqdibNM+5vWOmmBNB6mwnjO6f7VuRG3qW4V1TOV2HU7TMKNmi7KI2c20AsSND97U VLbyhCwH8UpAfEpd7GIFctQoFPZrWlx5dkTkHS/WNaeVoVATONNPPCOYlfNfTOVF WDNMDIgqfMvD6IQUy4IeTiG0InWEIB+yA1N/PFCRBwgy1rUVlsuP9bO/OSpgfME+ Wm6lWkXuhL0qOXGOCCr0HupkJMCjoLpShQRVaqZjhzevZwJCEJYc8K6URvYKksat GRnHyrnZERO1FeKPOYx3yZvGIRMyGofO9IMQFK93vGpMUB/9Pk7ejqi35ALGKkE= =RAHC -END PGP SIGNATURE- ___ 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] versioning system suggestions for a musician?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/2014 11:04 AM, Stephan Beal wrote: On Mon, Sep 29, 2014 at 5:59 PM, Inverse Phase inverseph...@gmail.com wrote: One thing that is very un-RCS-like that I'm trying to do is reorder commits. I say this because I have like 20 files that are all the same song. I need to just be like these 20 files go to this song/project and then decide after-the-fact which ones are oldest or newest. There's a very real possibility that I would discover an even older version of the track later on, so I need to be able to place something specifically before the first commit and so far I think most RCSes base everything off of whatever that is. I need to be able to go in either direction. That one criteria alone would seem to rule out _any_ SCM for this purpose (include good old RCS). i'm not aware of any SCM which allows one to arbitrarily reorder the history. git allows it, to some degree, but i'd be surprised if it can handle the level of moving around implied by the above description. A month or two ago I brought up this same possibility on the list, and the idea came forth that heretofore unimplemented control artifacts could override the predecessor displayed on the timeline. This wouldn't change the P cards in existing manifests (impossible), nor would it change the delta compression from versions (meaningless). It would only override the P cards for timeline purposes, much the same way comments, dates, and tags can be overridden. There's also a possibility I will accidentally commit the same exact version of a file from a different system — say, my laptop — with or without a different name, and possibly after I've already committed a newer revision of the file, which is one of the reasons I want that feature to be particularly robust. In such a case Fossil would record both commits but store the file's contents in a single artifact (because it recognizes them by SHA1 hash, and the hash would be the same). i.e. it would not duplicate the content, only the record of the change. The neat thing about this situation is that when you look at the artifact info page, it will show the artifact as being part of multiple commits, including those tagged with different branches. This way you can track down all the times when you had a given version. I'm also reasonably sure it'll also work for the case of multiple filenames mapping to the same contents. If you want to see if a given file's contents are already present in the repository, just run sha1sum on the file and go to the info page for that checksum. Feel free to type whatever URLs you want into the browser even if there aren't forms and links to generate them. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKbf1AAoJELtYwrrr47Y4HHcH/j9aK4hwYmazw5gqbpfAZX+O 8CjydYoBEn0gbNCssOvK6+v2QmegyL7M2K7smeIxS2xCn6zNLBSVjIFy4bPR8eap Vsjcr4PCqwQimz91WWGVlZ537Bv4MmmTg06pESQU0DzAhNgYUP9ERgg+6cuBAScy qJHAHndjOAi50I3arjQL38SXgmoPqVX74Kxe8qms/mz5E3btIV3kQh2WSKhlX/vG E+tc3SZHIRaTiAm00/BQcuGR0CzMnjqAc1z5N/33ecVlGtap3IQ3rC21mibm3Tys WX8sE3L6Wx2loaxZHw0W3HEIft6+UizKJ80qQ7XPs2KRZuQNCp6aQMUzMffy5Uw= =esHC -END PGP SIGNATURE- ___ 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] versioning system suggestions for a musician?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/2014 4:28 PM, Ron W wrote: Does Fossil hash only the file content or does it include meta data, such as the file name, in the hash, as well? Only the file content. Confirm this by running sha1sum on a file, then running [fossil artifact] with the checksum as the argument. You should get the file's contents back again. Yup, Fossil is so amazing it knows how to reverse SHA-1. :^) - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUKhbfAAoJELtYwrrr47Y4BvQH/1O/kO+ncw5vKpdi8dc6rCt/ cSQ/wDz2BKE1EOfxy+s1zIfozRaZx+/5Pwxc6RrUcjZry0kOf6bORya6RrBD8IVo bCFsrcQ0dQ+KPoAlwM96FoEoA9yMofN9jFbkdrrO6SfvHdXIuNh7Rm29ffttXr8n F3gbeOisWpUjXV2Ywev69FZly+gBvHJC6UEID9MTZ0r6wnfhrLSsoHGx0ktkGrUq 3roOyp810L4MzPkZaFTrRaS6kC8h/0WmSg2T+hJQi9eyPSnTTzTtnACWg6Mj7lF9 /kMfZMw4p2Yh4MYy5Mb6BLjM7paXn1BO21mwJeVeLCHeEuaJcxROR0JrCxP/IGk= =ejBc -END PGP SIGNATURE- ___ 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] Quiet mode for update and sync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/2/2014 12:40 PM, David Mason wrote: Right, what I wanted to do was get rid of the remote-url. It turns out that if you say: fossil remote-utl '' it complains that it's invalid, but now it's off, so it no longer attempts to sync. Type: fossil remote-url off - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULaHHAAoJELtYwrrr47Y4vOYH/j/uP+ZUaHZeO/RItqvW3jxe rOoN5MfUs+aIcpeFZapUvcZnpIksnjZsC8o2f/QFMK9DxT/RBx1uCXWOWXyYsuQm 9kuvohBpAM5haGLEwu9WEdYZzS6ca1M5UfubOETEbTq71Dn+t4LRnM60a44Wdb+0 +vGd6rCWmyyfZ0BZrSGRSM0agWYRk/TFijbJeJ8XTgl575MNzI8K+Fv74bKzA6Dk izA1cLeA/n6G+PkDlOksZAB/sEOr2dG6u2qXujSCgTJ5j4gGDDNigC4MpdaENU0k w3JydEr/eys/P+9YhXAUy/r4erkV+4O1i9ogmOf1y3mcDWptynOwoYIctNJSfIY= =qu8Q -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Updated SlackBuild script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sent SlackBuild an updated script to make Fossil 1.30 into a Slackware package. It's currently under review, but when it's done, it'll go here: http://www.slackbuilds.org/repository/14.1/development/fossil/ - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUvdhkAAoJELtYwrrr47Y4TUYH/3Eo3owCWblF7U40A99YUevb nxZcBVAwzJraGhSXibhywr+AuTBA/LyDzD/jpjWNTRceaPb8l0y8ubmQsqm6ddjy 2HC01tZAS3Spo4o3Plx5N0umZxEbu5Equn8OO/G6gpCuyUyJFpKxe69QVHsc/omP 63xc+qNqaNya0M0S8YIxCU2HuyzzMAo/cfwp48pFY53DcVkETbpyev1d8y+qOL3e Osxnm/CDZAeVvYAfZfCtJ2+UF5wOgf+2D62qIfE83EhoCYItweP7Uoc39IRO6laH uMb0IgjRMbO84w1ZVnVvksVqghRYZ6ZzMN+7WF34DBuOfwf4JoLcR5d9OzaHx5Y= =MsUy -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Branch color generation
http://www.fossil-scm.org/index.html/timeline?n=20y=cib=2015-03-18 dotfiles-setting and svn-import have very similar colors, as do git-import and timelineAntialiasing. dotfiles-setting: #AFC3C8 svn-import : #A2BABF git-import : #92C1BB timelineAntialiasing: #8FC1BC I know it's just bad luck that we have several color coincidences at the same time, but even so I wonder what can be done to improve hash_color(). I see some work has been done in this area. Has it gotten any attention? I ran f merge -cherrypick viric_newcolours in my Fossil checkout then recompiled, and now the colors indeed are easier to distinguish. The /brlist page used to have a color test mode. Is it still there? Hmm. Yes it is, just append ?colortest to the URL. Running it gives disappointing results. Numerous branches hash to precisely the same color, that being #A0C0C0. A couple other colors repeat, e.g. #E08080. Probably more, but right now I don't have time to make a full list. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] many duplicate links @ www/permutedindex.html
On 3/20/2015 6:59 AM, Svyatoslav Mishyn wrote: $ sed -ne 's/.*\\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort | wc -l 163 $ sed -ne 's/.*\\(.*\.wiki\).*/\1/p' www/permutedindex.html | sort -u | wc -l 49 $ sed -ne 's/.*\\(.*\.md\).*/\1/p' www/permutedindex.html | sort | wc -l 9 $ sed -ne 's/.*\\(.*\.md\).*/\1/p' www/permutedindex.html | sort -u | wc -l 2 This is intentional. A permuted index provides many links to the same documents, permuting the name each time. For example, a document titled hello world will be linked from hello world and world — hello. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Veracity Version control
On 3/11/2015 2:08 PM, Graeme Pietersz wrote: I just experimented with a new repo Even if nobody has no privileges, anonymous can login. True. Take away all of anonymous's capabilities to remove the ability for anonymous to log in. The documentation needs to be updated to say this clearly. anonymous does have some privileges not inherited from nobody (hmncz) anonymous doesn't have z by default. and these can be used by directly typing in the appropriate URLs. I have not tested everything, but I have verified the biggest weakness: anonymous can download a zip archive using the /zip url. h affects timeline, etc. generation m gives /wikiappend n gives /tktnew c gives /tktedit z gives /zip -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Veracity Version control
On 3/11/2015 8:58 AM, Graeme Pietersz wrote: On 11/03/15 12:25, Andy Goth wrote: All you have to do is take away all of nobody's privileges. f user capabilities nobody Can also be done with the web interface. And the same for anonymous surely? No need. anonymous inherits its ability to log in from nobody. Taking away nobody's privileges also takes away anonymous's privileges. The user administration page says: No login is required for user nobody. The capabilities of the nobody user are inherited by all users, regardless of whether or not they are logged in. To disable universal access to the repository, make sure that the nobody user has no capabilities enabled. The password for nobody is ignored. If you like, you can explicitly move nobody's privileges to anonymous so that anonymous login is required. You would do this to give every human access but block spiders. Login is required for user anonymous but the password is displayed on the login screen beside the password entry box so anybody who can read should be able to login as anonymous. On the other hand, spiders and web-crawlers will typically not be able to login. Set the capabilities of the anonymous user to things that you want any human to be able to do, but not any spider. Every other logged-in user inherits the privileges of anonymous. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil 2.0 wiki page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I added a few suggestions to the Fossil 2.0 wiki page https://www.fossil-scm.org/index.html/wiki?name=Fossil+2.0 without discussing them on the mailing list. Probably a bad idea, sorry about that. So I'm drawing everyone's attention to it. The ideas I've posted are: ### 1. Show cherrypick and backout merges in timeline and context. Differentiate between normal, cherrypick, and backout merges by the shape of the arrowhead. ▲: Normal merge (or ◀ or ▶ as appropriate) ⭕: Cherrypick merge (resembles a cherry) ❌: Backout merge (signifies removal) The merge lines may also be shown in different colors, e.g. green for cherrypick and red for backout. Suggest allowing this feature to be configurable via theme. Also may be a user checkbox to show or hide cherrypick/backout merges. ### 2. Require directory name argument to open command. One thing that repeatedly surprised me when learning Fossil was that the open command opens the repository into the current working directory. This left me either confused at there being no apparent effect (except a hidden file called .fslckout, in the case of a new repository) or angry about Fossil making a big mess in my current directory (not easily undone because close doesn't delete). I would have picked up on this behavior instantly had the open command required the directory name as an argument following the repository argument. The directory would be created if it doesn't already exist. For example: fossil new repo.fossil fossil open repo.fossil repo cd repo Opening into the current directory could still be done by supplying . as the directory name. fossil new repo.fossil cd repo fossil open ../repo.fossil . This change would resemble the behavior of the fusefs command which requires a directory name argument. This definitely hoses every script that calls open, but that's intentional since the goal is to force the (inexperienced) user to confirm that he really wants to open into the current directory. For current Fossil, a compromise form could be implemented which defaults the directory to ., but Fossil 2.0 would remove the default. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+LtPAAoJELtYwrrr47Y4J7oIAMbNIOi5f9LqkOGbaINlSmrl MNs1iFkbOYvJw05j73MrjCNIxfrvqK3qnssvUhXvStLW8X6/r8Bz8IVzgYA4Xs/R +QgVYVG5sKw9yqhwqAfOZWw8F9eKzVgk02IymHVBQ4WwZT5/tp+ug9loOEcw6zqb Vs00eXrBBqGNWKapAFxW7vgBRNuhX/uy75MH0cZnfVEo/cCjkgiKagUXlW6vMoKp eJAdErU2JuSV5phiG5eAThvnRGeq6OuoBlCf0OcosYvZP/YahxyahUxqBK+Li5Wk O+V98xSfVouyPPYQ2Hjv2LXCpP4uo0dSmjn+1QljE3t5FbSDlO0EeGRUkqo1U90= =QJgu -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] /tree vs. /dir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What's the difference between the /tree and /dir web pages? /tree has more options, but it seems to support everything /dir supports. Can't /dir be made into an alias for /tree? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+LKCAAoJELtYwrrr47Y4ZLMH/3ZIGYVuCIuDG2DUXlv4tQvY iO1BX4iyo6t4txOnM0rwR1/JZuH8PHyR3JBYgh3D989vuZYYx0FtuftpjnyP3Ner k3wWZ1oghDEA+RZpY0j2WlYjW+1gS/O0UwMMLXS+KpL4HRxJGjg8RoJn6+d87Vv8 v+mSJPwBM/jleSzUGKkJigDSKrH+UzOuNb8q3tftB9d6L33tNuVcF6c4JbhQpNlI HZCNJdHVQzs6bjKLtfHqkctotw15KOB1cRPyVhHoVsDbu83RE518BmxE7l7ybTKP SX76dgPnkoK8ApJai7b43bWI0qWhNxXMJkwov2AaWoBnfA2ThJITKvxpR2pj5kk= =VHMZ -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Re: Fossil Fuse (was: Justification for two-step mv and rm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/4/2015 6:02 PM, Ron W wrote: Fossil can act as a FUSE server. I haven't tried it, so I don't know if it's possible to check-in files by writing them in to the mounted file system. This command uses the Fuse Filesystem to mount a directory at DIRECTORY that contains the content of all check-ins in the repository. The names of files are DIRECTORY/checkins/VERSION/PATH where DIRECTORY is the root of the mount, VERSION is any valid check-in name (examples: 'trunk' or 'tip' or a tag or any unique prefix of a SHA1 hash, etc) and PATH is the pathname of the file in the check-in. If DIRECTORY does not exist, then an attempt is made to create it. Fuse support in Fossil is read-only. It's useful for viewing checked-in files using non-Fossil programs such as diff or grep or vim or any fancy directory comparison tool, and that's about it. I can't imagine what a writable Fossil Fuse could sanely do that can't be done with a normal filesystem. Fossil commit is a high-level concept which can't be comfortably represented in the OS's filesystem API. Mapping POSIX file writes to Fossil commits writes would yield a messy timeline full of intermediate versions; temporary files; editor swap files; spurious adds, deletes, renames; exactly one file per commit; and no comments or merges or tags. grep, find, and the like can be used on a Fossil Fuse mount, but only within versions explicitly specified by the user. They can't search through all versions unless the user supplies the complete list of versions. This list can be obtained with commands like: $ fossil finfo -b -W 0 FILENAME | sed 's/ .*//' $ fossil timeline -n 0 -W 0 | sed -nr '/^\S+ \[(\S+)\].*/s//\1/p' I'm not saying Fuse support has no room for improvement, only that it should remain read-only. One thing to remember is that Fuse isn't tied to a particular checkout, so it's not even clear where changes would go. I've considered a few possible improvements, but they are either bloat (features in search of an application) or have a fatal corner case. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+MGIAAoJELtYwrrr47Y4f0kH/02L/5MXKUXNVfuzJaNOYCse fJA7U+Xu3nHcGolMQxz/Di9kQ+1KvM9jJb2aJskMxBAJtu7LvcvPgb3AeUKeLWOR l4hNtrOknIHs5HvKevcKi30yNVX3bCfRkq8q6Ngey9QxX5VnD4m9oNGUh9Y9JF/i pqZ+ZNs9a4DtfJVaMQa4y9dkcCiavPfRgm6IMS6VRq14CrWtSQMbfAT2l2fKs3wD oX6jN/Ic6Ivd3g3ElshYQAS4Uxz6O91O1ba5iRgV1u5ua8mSHIeXTVGFk+zeUwqG Z+xIbE4RLoRj9mIrKgGL3e+Pa8Zmoq8IwWS3/Ms2GF/31iHca9UqPqvOHhd1ZGA= =p8OC -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Like-named dirs and files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If a file and a directory have the same name, the file is only visible in the all files web page when in flat view. In directory view, it only shows as a directory. If you want to follow along at home, type: f new test.fossil mkdir test cd test f open ../test.fossil echo moo file f addremove f commit -m 'add file' rm file mkdir file echo moo file/file f mv file file/file f commit -m 'rename file' f ui Then click Files. file will show as a directory. Next, click All. Separate entries will be shown for file the directory and file the file. Next, click Tree-View. Now only file the directory will be shown. This problem happens both with /dir and /tree. I see no difference between the two. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+LixAAoJELtYwrrr47Y42bkH/1b8jLVbYB1LZIqysU6zT1oB yzM8W6DNqITvSCI6+hKXritOH9XE9kvQhbEN/zGOpDbAuDJ4cRp7L4rbbFCULqeb 5RIrL+TWqj69JcACtnalcGMqi45MbKhgmhLGK7jm1HLbs6W52R/DX/ICJU/KKo3E ZPmJz/kLNFO+bpLFzDFWZ4/7nilG/CiYhMGoAGa5756dnMYv+rrXyYRNZlKSV8N1 R/wLm4Ma5OawJnX7BZftxGc/EQ+sgBRKn9HtIBxGRHaFfmkvqFfOTniv0Xlc42K3 P8zKdYwP240vj7pwgFmhwVdw0SLzSuMZDQdSgcLUgSbnEI4glQSCEWU+m6tNptI= =g6zI -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Availability of shunned records
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curious about the list of shunned records in Fossil, I asked Google to find a few. It located the very first one I asked for: 0188ed1fcae4d2606237804160ce87edf4b7e160. http://hwaci.com/cgi-bin/fossil/raw/0188ed1fca.txt?name=0188ed1fcae4d2606237804160ce87edf4b7e160 Why hasn't this server received the shun record and either purged the artifact or at least stopped sending it out? The artifact itself is a ticket change artifact with date 2014-10-05T11:14:14.614 so there's no excuse for the shun record list to not have propagated by now. I tried again with what I presume to be the main server and got 404: https://www.fossil-scm.org/index.html/raw/0188ed1fca.txt?name=0188ed1fcae4d2606237804160ce87edf4b7e160 - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+MZNAAoJELtYwrrr47Y4VLMH/R01eMWHLFFlfk+jHOZB4N0j ov+Vrh3N5dpT10s4F8pCssxpA4zBuaBB4vXG2KPQ6ebkCtih1w/m9usKhZHy9/N8 hQoGw+bQsPpE2XuO1phcX4sBeBH7whQ3jM2N2Wrs5L/OkfKcDfNM/q0oM+Vltbr+ OgTrAn482t4j3h7U8mjoX39VylLV5F7PRlK4M/pYJWgkyMyFLcigrt+4GKh2q8A6 oKg2lXYXgEtVJ+sVVO0gcXod0yBmKR4dHV84ss1hlZkT7dmUyjMpw+rC1zG7+J0R AnZBZdwJpkx3DsD9V2tS7jr3UGZH7HOqJkI8e6U0jdrfrxwFWh335HQoB/WWpaY= =EJqh -END PGP SIGNATURE- ___ 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] Availability of shunned records
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2015 3:10 PM, Andy Goth wrote: http://hwaci.com/cgi-bin/fossil/raw/0188ed1fca.txt?name=0188ed1fcae4d2606237804160ce87edf4b7e160 Using this basic URL against the entire list of shunned artifacts, I was able to download the following shunned artifacts, sorted by date: ce1cd083bf57ffe71b737adc3bf7b878ff530283 2013-09-08T20:09:01.676 3486368700a5a056e6919a0baee2f276699dcd38 2013-09-08T20:09:35.834 3c83b46ffdec4e2e54540b7005ba6bfbc7d6ffdd 2013-09-08T20:13:31.141 0bfbce4c1e1ecbf6c442cac4344898e735fae304 2013-09-08T20:13:57.919 733a2627a24d24782e2d0605526baa6bc89ae260 2013-09-08T20:14:14.520 8e2bd52ced64f6a7be449a332286fbc79d556d04 2014-10-05T11:10:37.262 0188ed1fcae4d2606237804160ce87edf4b7e160 2014-10-05T11:14:14.614 They are all ticket changes. I don't know if this is because there's a bug in ticket changes or if ticket changes are the majority of artifacts being shunned. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+MjaAAoJELtYwrrr47Y4mMkH/1elZYSiPR4KSfvPblVQoEvm Zar91x2l7yfLH3l9hhF8tKUXM7GV39UWTM4chTnNWQeYf4FPU/X5L24jUR001kJR sncnPu5lzlRixxAc77HZb6pgxRU+ljF8OVG/iF9Tn5Mu0u2N8NHXEyvq7HtlVVlw 3gJrpd79w5eqACY9uSTpFPdY8bRFIujkuMmEnXT3Pr5mBqYYrUi8uMiXzldQurl3 C5wdmLNgKFNLDdmDyr4Y7EitoAb2bfxc0gcAfssemrCUaTv5FVWt8eGW9TeNFuew 6QwXLqTdA+P0DwxE1XEdvwRP5KkSubKzBfh0Sp+UALBdBmzMRnD3TizcbKaxpiA= =C9H6 -END PGP SIGNATURE- ___ 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] Fossil 2.0 wiki page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2015 3:54 PM, jungle Boogie wrote: On 5 March 2015 at 12:23, Andy Goth andrew.m.g...@gmail.com wrote: ⭕: Cherrypick merge (resembles a cherry) ❌: Backout merge (signifies removal) FWIW, these are tiny, faint boxes in google chrome. They're Unicode characters \u2b55 and \u274c, respectively. If you don't see them properly, there's a problem in your browser or operating system, or you simply don't have a font with these characters. The characters also appear in this email. \u2b55 is a circle, and \u274c is a diagonal cross. Could have said O and X, but these characters came out prettier, plus there aren't good ASCII equivalents for the triangles. ^ maybe?? In Tcl I'm able to type puts \u2b55\u274c to see the characters. TH1 doesn't seem to support \u notation. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+NVmAAoJELtYwrrr47Y4pAkH/2dMtCEt9TH4iIjxphhD6J// k1CLgFWo2hY3RbMuxAhBPWJ88lQizYz4GPmfVf4qLi/zJ8za4ArSgTyf2ChORclM 7vn951o46EAJyS+tnFZnOLT+13ojfXS9KzYWGM2pKgPcUN7YkQOs2q21uGctMJ+F tjcKxwIgqDOKlHXub0Os5y+eWN29HwKiM7b6ySzKdGmZvVY4ux0gd+vKYY0ip8p+ g7pfJ8vjKKhc7LzjlLiJfN4TdI8q6nU9FlOngFtbEhfu747SjnMhg4ZBbJHwdKi0 y74Dn/ZcNenStXD3rQ9oljp0T/d8x5wPk/gYsdhsNGrgKhoPayrq10cqM5kYNmk= =JCgX -END PGP SIGNATURE- ___ 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] Fossil Fuse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2015 5:16 PM, Ron W wrote: Many years ago, I attended a live demo of Clear Case. At the time, it was mostly a VCS with a file system API. The timeline mess you mentioned was mitigated (partly) by, as I recall, adding a command to the makefile/build script to signal CC to label the user's current view as a successful build. (A point where a Fossil user might do a commit.) All the intermediate file commits were still in the repository, but the time line report defaulted to showing only the build points. Also, as I recall, CC could be configured to automatically pop-up a window to enter commit comments. Actually I've used ClearCase for ten years, though I have no doubt my organization's configuration of ClearCase is not representative of what IBM/Rational would recommend. - From my perspective, ClearCase avoids the timeline mess by having a separate version tree for each file. To correlate the logical equivalent of a Fossil commit (i.e. collection of changes made for the same purpose at roughly the same time), the intended version of each changed file is given what we call an activity label, which manually correlates to activities in a companion product called ClearQuest. For a build, each version of the file that makes up the build is given a build label, once again manually correlated to builds in ClearQuest. In an attempt to maintain consistency, we have standardized the check-in comment format to include the engineer's name and activity label, and the database is (typically) configured with a trigger to validate the format and apply the label. But there's nothing stopping the label from being removed later, and in fact this happens every time a subsequent check-in happens on the same file with the same activity label called out in its comment. I once privately approached drh about the possibility of hiring him to import such a database into Fossil, but further reflection has made me question whether the result would be worthwhile. He may succeed in importing the stuff that works the way I describe two paragraphs ago, but what on earth would a script do with anomalous ClearCase commits that defy convention? Examples: unlabeled commits, multiple-file commits with labels in conflicting order, multiple commits to the same file with the same label, inconsistent branching. Even worse, despite the fact that ClearCase supports renames, we prefer to delete and recreate. Prefer. On some projects we instead wound up with a mix of that and branched directory objects. No clue how to normalize that. I'm not saying this is better (or worse) then how Fossil works, only that is how the version of Clear Case I saw worked at the time. The person demo-ing CC talked about how The Clear Case Way as near painless as possible for the developers to work with - no need to configure editors or IDEs to support CC, only one simple command to add as the final step of a successful build and only one simple command to designate a build point as ready for integration. The integrator/release engineer had additional commands, but the assumption was that that person was a process specialist who would actually want to use a formal UI. ClearCase is modeled closely after the traditional filesystem interface. In particular, it versions directories as well as files, though that is a major, MAJOR source of complexity. Adding, renaming, or deleting a file involves checking out its parent directory. In practice, this is so complicated that we lowly software engineers have to make a special administrator request to add files, and the request may take a few days to be fulfilled. Renaming is forbidden, and you don't want to know how we've chosen to implement deletes. As for the graphical user interface, at my organization everybody uses it. Very few people stick to the command line or even use it at all for stuff outside creating a view in the first place. I'm a rare exception because I love to script things, but most folks around the office will do everything in the GUI even though it's creaky and requires an hour of clicking in order to, say, check in 100 changed files. This level of automation can be accomplished with Fossil (or Hg, git, etc.), but requires more configuration by the developers - or that they all use a preconfigured IDE, selected by some one (or some committee) within the company. I haven't encountered any IDEs with ClearCase integration. All my ClearCase experience has convinced me that a well-design version control system cannot be directly integrated with the filesystem API, that these two concepts are at fundamentally different levels. It's imperative that commits transcend writes. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+O1hAAoJELtYwrrr47Y44bcIAJQ5X8VnjSzu+TtaHTH+AgOF lZyqXyl22M7H7sPdWZyUeQaAV3prTPQEhe8Y
Re: [fossil-users] Fossil 2.0 wiki page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2015 5:12 PM, bch wrote: I think the ⭕ is not a good cherrypick symbol. It's closer to a cherry than ❌, for example, but still not really close to a cherry -- the circle, and the color have well-known symbolic baggage associated w/ them that (imo) ought to preclude it from being used as cherry-pick. Better off w/ , no? Also, bear in mind that not all web access to fossil is via a utf-8 graphical browser. That's actually my point. I picked symbols that should be easy to render without special support. But in the wiki page, UTF-8 is the way to go. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+Oh3AAoJELtYwrrr47Y4FygH/2nNiLYHO3xWd1WL48zSB31I GovY+B3/51gBjmJN1Knt0LGJdYhispsbUh4OwwO4sG0OUOFT0n8abuKGUFtM0x/o gKihqQKkxx1eYdiyQqm+biKaelstLMNBI3elEbCk65V88hXKN/4yY3aqyqB9EQec +jOkQv9JN2JJwhahvgHscSII5I6iZCA3ENAwFD6GhMm0IsIb0mz//Pbe1UywBNyG YOuzgTyA3KfeDhQpI/7IsPt/f9+cHNcWnom2C/O/FgCekeAIXaLWfAb3HtRONIn4 07mYYc3CuAgDPM7yfaTd9YHJ/e00708Tn5tcJuA3g+O3dCnozP3xPLb8oNjxfbA= =dMCq -END PGP SIGNATURE- ___ 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] Fossil 1.31 directory name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/3/2015 1:59 PM, Andy Goth wrote: On 3/2/2015 12:49 PM, Andy Goth wrote: On 2/24/2015 11:31 AM, Joe Prostko wrote: Yes, I wondered about the directory name not matching the filename, but just modified my Haiku build recipe to account for it. I'll be sure to change the recipe file once the tar.gz with the full path is in place. When I have time, I'll have to do the same for the SlackBuild script. Done. I will post again when my submission is approved. Fossil 1.31 has been published to the SlackBuild website. http://slackbuilds.org/repository/14.1/development/fossil/ - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU+479AAoJELtYwrrr47Y4/lYIAJjXOeQnU0Kc5H9Xq3wb6MpV uZJ40Y9cemyCCywa8HUMl5mS9dJZGQkaeqYUmflhnufvdthuK7LesTZO0kS0PBLf nLxEa/3YX5gkCqRtTr0VS/lMmYjfXLw9NMOCqeU+WUlODhjUyS6i3cxL7d7ALDqt 2caAbLE9PWbkVXdZx1vqxUWO+HQWxrEaHMC4vChKPo/TNnrY1y+bjfoZaFV5Gaun EJUAce3RTBHSVdXZ4d1fUkz6OiUQAaUKjZd3DSCq2H3nGepkMYLbhQWqXhD+SYej H9S5Gl6MKHKeGNuhEhPyk43fXtQoIM+QpyFdnQDGKyAWmkLxjtVAyxBc/DtUA6s= =9keh -END PGP SIGNATURE- ___ 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] Veracity Version control
On 3/11/2015 12:15 AM, jungle Boogie wrote: I created a test repo with a few commits: The commit of the 100 MB files took about 300 seconds but this ran on a single core 512MB-1gig RAM machine. I know this is unscientific but it seems fossil handled the large pretty commits well. If this were done on a machine with an SSD and some more RAM, it may not take quite as long. Please try again but with repo-cksum turned off, see what difference it makes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Timeline graph display options
On 3/10/2015 3:47 AM, Steven Harford wrote: I prefer (2). It's more concise and looks great in each of the examples you provided. Therefore, I'm not sure it's worth maintaining both display styles in the source code. Agree. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On 3/31/2015 11:18 PM, Matt Welland wrote: On Mon, Mar 30, 2015 at 10:57 PM, Vikrant Chaudhary vikr...@webstream.io wrote: fossil clone --cheap file:///path/to/upstream.fossil new-project.fossil +1 I think I would use this feature should it ever come available. I have 500M+ repos where a cheap clone would be quite nice to have. I assume the feature would work whether the upstream fossil was read only or not. The benefit would be a clone that takes a few seconds rather than several minutes. I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. If users could somehow share repositories without copying them in full, that would help a lot. A simple test showing how Fossil repositories cannot be shared is to attempt running two [fossil open] commands simultaneously. With small projects this is hard to do, but you can just hit Ctrl-Z during the first to make it take as long as you want. With projects such as those I work on, [fossil open] takes a few minutes because (1) there's gigabytes of stuff being written out, and (2) we're always stuck with obsolete computers. So sharing any given repository file is clearly out of the question. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Fossil 1.31 directory name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Feb 24, 2015 at 12:02 PM, Richard Hipp d...@sqlite.org wrote: On 2/24/15, Andy Goth andrew.m.g...@gmail.com wrote: Unlike previous releases, the unpacked directory name does not contain the seconds. This means the directory and archive filenames don't match, which is a problem for the SlackBuild script. Are there any plans to reupload with the directory renamed I'll get to that as I am able. We have a bug in SQLite right now. You are in queue Quite some time has passed. I assume you're not going to reupload, and we're stuck with the directory name as it is, at least for this release. On 2/24/2015 11:31 AM, Joe Prostko wrote: Yes, I wondered about the directory name not matching the filename, but just modified my Haiku build recipe to account for it. I'll be sure to change the recipe file once the tar.gz with the full path is in place. When I have time, I'll have to do the same for the SlackBuild script. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU9LC8AAoJELtYwrrr47Y46W0IANwjkJ5ciNZ9te1SA+JJS6rN ZMJ5/f5st7pgj8POkcI6G4Y6WQzNtqHbq06uON8llrVPSEZfyQLlI5cxd52QPIjd 0soz8wAjfBf3XT/tCf4OcnhSa2QRSSjy5saH2agle7KxyQoKbsIyRrcPl6u4AkY5 yTrKXHl1GSbgyNgUtGHfH3hdbjtIgIevrEytJmHXJKhqi04orbwG17AyU0BO6n+9 5agEsZiuRL4zROGu/bu9FSyq2f0wLzQcTHiM0dkJVVqnr24G2b1/KoSD83oOZnVg Wgf7iEy7lSLWT1uhhOn3YyZGQBCqBwnhMQK6ZmmpPaWZmnDPY90Fr48sIFO74Mg= =XYFe -END PGP SIGNATURE- ___ 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] Fossil 1.31 directory name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/2/2015 12:49 PM, Andy Goth wrote: On 2/24/2015 11:31 AM, Joe Prostko wrote: Yes, I wondered about the directory name not matching the filename, but just modified my Haiku build recipe to account for it. I'll be sure to change the recipe file once the tar.gz with the full path is in place. When I have time, I'll have to do the same for the SlackBuild script. Done. I will post again when my submission is approved. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU9hKwAAoJELtYwrrr47Y4od0H/2zhvm6YGxk5ok0mM1A+RWie vE59IwZC0kcQtjcv/38FTsc+tl2Ke4ciMAXwedS78khg7hWLoUTFSMtsexPltDfo byd00cawLWRVz8AOCmnBFHGHUyK3g3HJXEubmXT3uovxa+620gmPx5TbHfk2zEz5 9+z5vHCyFJY4/lUK7rMaYSgwf+r0Wx5oB/NzoXiLY408mMkWrstjr4gVhYGa3oVS gQJxUtyco26wOi3UWs8QLGt6caQqbVub3kVayToufi0q2cOGow+M4kccD8imIR4y 9SQZFIZmxgBb9H5WFdWCQ1wddjl/Im+kDq8oJwz0SxppG/z73eUOoH/WHXElRlI= =6C7l -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [fossil update] gotcha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This probably isn't news to anyone, just a gotcha that I ran into, and not for the first time. Figured I'll describe it on the list and see if anyone has any thoughts. This isn't a bug or anything; Fossil is behaving according to design. It's just a surprise due to not paying complete attention to what's really going on. The other day I did [fossil update] in my SQLite trunk checkout, got version [c6399958]. Today I did [fossil update] and stayed at the same version despite pulling many artifacts. [c6399958] started life on trunk but later moved to a branch, so my update kept the checkout on the branch. The record shows that [c6399958] inherits sym-tkt-2326c258 from [c0f4e308], which was added by [1e3cf43e] a minute after [60161b5f] updated the comment to say that the change isn't a complete fix. My naïve user perspective is that I started on trunk and therefore every update should keep me on trunk. But that's not the full story since the checkout version's branch can be edited. If I don't pay close attention to changes in branch, I will be surprised when my future updates stop doing anything. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU9fiAAAoJELtYwrrr47Y4PkQH/i//B8un6qs9KVvMwX4IIh4v NmXU0Z6+XqWDGEXDMtEj4JFzYvfckMzStc1xFOnedZbKr02Hyix1L25ZcTtcDWBe YB2Fb9iVzupyLUQ6QoWwA1dUQQJi3GDHEpY/h7sjgW/Cx3bs41iRaB3RTrTiShrl EhTIcuyKD2ClV/+lxXQxcIloamb/S1JdEIpwYjLro+K8/n7LHZTFTFKHe2+5kz9J deM9OAg4dbq4h5cMK4IyOQ/sD/wHCJGjpMPHI69ii8UKXcqAOw4apWo0e74hTJmP LhBdjZwt2XgrFLuHNa6rx+ztQDoci/E8+56YSkw/N4/sGDvi8OI5gb0JSMmGrvY= =JLsE -END PGP SIGNATURE- ___ 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] Fossil source download naming scheme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/2015 3:21 PM, Ron W wrote: Took a quick look at Fossil commits tagged release, I see tags like version-1.31, version-1.30, etc. I also see references to SQLite versions in the form x.y.z as opposed to a date string. Seems like x.y or x.y.z version numbers are already entrenched in Fossil. So just grab the file at this URL: https://www.fossil-scm.org/fossil/tarball/fossil-1.31.tar.gz?uuid=version-1.31 and be happy. The file will have the name you want. Or replace 1.31 with whichever tagged release you desire. The feature you want already exists. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7PFdAAoJELtYwrrr47Y4DAgH+QGwXmn8hA1PopVf6QaLfN4f 1qrzlSHX9BfdZJq5rNudvJMcg9GM2Bv6TKrHYUvny/m8OJHpToEV74NzvriRQwES C3YWesphl54ZrKXdLw/GqUspKRXF18feg2eTVkh2smrYgExNpXi0rJLHjdw9AjQh DiKHWq9qG+OZEtx54ALHZrYnQPtUS+rpWVTczQ7oWdp1wUtXQAPoybL3YDdMvdd4 uf1J/aWWiK1Fm7u8V86TWSkWAZHSqq0jzYVsfkdOzk87NUtnrgAMGFY6LO3JNbN9 8OlFW7Nftc2T8k0BVywudm388hZcWOL/vG897hJPot4Gu2dbQ+zlwnl48UPM6Lk= =daCa -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil 1.31 directory name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ tar tzf fossil-src-20150223162734.tar.gz | head -1 fossil-src-201502231627/ Unlike previous releases, the unpacked directory name does not contain the seconds. This means the directory and archive filenames don't match, which is a problem for the SlackBuild script. Are there any plans to reupload with the directory renamed, or should I modify the SlackBuild script to strip the final two digits from $SRCVER to get the directory name? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7KlrAAoJELtYwrrr47Y4OYYH/1ll1UXrS0EIAhL157gChqTy pq74tLRwLy7Clc+ouK0C4t7LM7/tE8GE0aPyr5WRuENdSLNz/wgYt2Uj/RHPWwi7 bj8wVViQojHMgLesMCt6DBRbzVBuJdVJTaYVNeRiLbO0+Vb/lvdkX0TgMy3LYV7e 7hzlsZeK9HyhW2oNv6SkwsKw2fN7Q9tlQzUnQPPoLh2//52H8ORPL1YmWjpokbtc gNuyb6jdMV13DE3rJHiPYIxdrqtXvLP4tN/GgHfdTd397DJciCJK2YleDyjL/mFd 3miBBHjAvU71nxaNEa3G4pbfJyr9zgkmjMGLa9vTtuQGqxwXpAQrrzyUlsAhgek= =T4/h -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] select menus and back button
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The new select menus don't play well with the back button in Firefox 36.0, likely other versions too. After pressing back, the menu shows not the old option but rather the option that was selected in order to transition to the new page. For example, start with Check-ins, then select Tags, then Tech Notes. Next press Back, and while tag edits are shown, the menu still shows Tech Notes. Pressing Back again shows checkins, but the menu shows Tags. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7mTcAAoJELtYwrrr47Y4XBYH/36DYrfMl7vfWd2zE+4fBgd5 t4Sm70j2z7vzVYkUfRW6y6Fwbkc92sJtmu1fiD0wCeyFNgZZ96vf/G0qJ2RG0XwX 4q4ODQZLUMZwPPY7AJzOaGyI6z3xPN2AJpPk+aWti+YnNgI/n5SH/ISP/p253vw6 YQ35UUEXSUqg/4kwqUnZHImevfBi6DbT72Z9SFxjgHZBRUuxXXjBxKtfLFZiXTD1 /Nwg+Vew5LEMr4EC471wpdxPWVeZ8iPPjQJbwwbRppdRz4L9NRl7Ot+Yq7kDhW46 ccBoJLRJkGr+ts0skbvsXdr00KCl2JBYSUPg0g0tHerKyBmjrrk+/256iZeNYzU= =eNSs -END PGP SIGNATURE- ___ 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] select menus and back button
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/25/2015 6:32 PM, jungle Boogie wrote: On 25 February 2015 at 16:12, Andy Goth andrew.m.g...@gmail.com wrote: The new select menus don't play well with the back button in Firefox 36.0, likely other versions too. After pressing back, the menu shows not the old option but rather the option that was selected in order to transition to the new page. For example, start with Check-ins, then select Tags, then Tech Notes. Next press Back, and while tag edits are shown, the menu still shows Tech Notes. Pressing Back again shows checkins, but the menu shows Tags. This wasn't the case for me on firefox 36 windows 7 home premium 64bit edition. Point for point, that's exactly my same configuration. I did observe the with/out files section remains as with files as you navigate to other options, but only check-ins actually have files to display. Easiest way to demonstrate this problem is to go to: http://www.fossil-scm.org/index.html/timeline?y=ci which should initially show Without Files. Select With Files, then press the browser's Back button. At this point files will not be shown, but the select menu will indicate With Files is currently selected. This is just another demonstration of the underlying problem I described in my initial email. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJU7mwDAAoJELtYwrrr47Y48G4IAK41l9UZGiEDPnPvZHS14W58 lR4nBrFjguoKsU7j1R4vCZ1a7G0yMiWxBm4obVVwWf0KNITxJ5l8CVNLJ7Sa3nEP Mf3ZkszXQ3ozQBcHBkd7jR8u+4o7HcMR1/iGBgKCx80osBY7UKNWZvGrLHZrY/Mu eUGHxHkpjDWBxeNFed2XmcyzwPId4nH91Tx0ID+Wwv2sbgKqj4bzn/wFeYaAVT2c mtiwvTAj+prx4JZucgwTXYm0uFli4chCOJhDK4Q7zQ+OV/0bwukAWcthCKhwjsE7 UObFOPiNKVwSmgsbRKoG4RsNQ6tIC7QwM/9ztOuNduhdhQxwZiPI2FqcbJywa7I= =VFjt -END PGP SIGNATURE- ___ 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] {fossil-users] symbolic name tags
On 3/23/2015 5:44 PM, Tontyna wrote: Adding tag names with and without sym-prefix to a repo I couldn't see any functional difference. Did I miss something? Pretty sure if you try (and don't use -raw to inhibit the sym- prefix being added), you'll get a tag with a name like sym-sym-whatever. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Introducing Lagerstatte, an open-source hosting service for Fossil repositories
On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote: I'm thinking about how this could be used at my workplace. On some projects we have shared computers called viewservers (view being a ClearCase term) on which we create our sandboxes (again, CC term). Switching to Fossil would mean each user getting his or her own copy of the full repository which synchronizes with the master. Furthermore, each user would need a separate copy for each viewserver because it's best not to share SQLite databases through NFS. This will eat a LOT of disk space. If users could somehow share repositories without copying them in full, that would help a lot. You are probably thinking about a shallow clone. You'll have to tell me what you mean by those words. By clone --cheap, I was thinking more along the lines of ATTACH DATABASE. I.e., collecting missing deltas from upstream db which is attached to main db. Which also means that upstream repository must exist on file-system (no http). The impression I get is that we're both talking about the local repository containing things not sync'ed upstream, for example private branches. Truth is, I need to understand more about Fossil internals to make any assertions on what is possible and what is not. This is a dramatic departure from the current design of Fossil which directly opens the repository file, which is an SQLite database. What you suggest would require frequent communication with the repository at the remote-url for doing many kinds of read operations. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Limiting HTTP/1.1 host
Seems I have a lot of people trying to access my repository who have no business doing so: [andy@toaster|~/fossil]$ fossil info myprojectname.fossil access-url: http://2015-02-23 access-url: http://216.114.41.82015-02-23 access-url: http://216.114.41.8:80 2015-03-05 access-url: http://24x7-allrequestsallowed.com 2015-04-01 access-url: http://5.61.43.116 2015-04-02 access-url: http://66.160.219.98 2015-03-06 access-url: http://66.160.219.98:802015-03-09 access-url: http://dns.cloud.ph2015-03-10 access-url: http://google.com 2015-02-24 access-url: http://httpheader.net 2015-03-23 access-url: http://s1.bdstatic.com 2015-04-24 access-url: http://testp1.piwo.pila.pl 2015-04-08 access-url: http://testp3.pospr.waw.pl 2015-03-05 access-url: http://testp4.pospr.waw.pl 2015-03-10 access-url: http://toaster 2015-02-23 access-url: http://toaster.x. 2015-02-23 access-url: http://un.is-a-geek.com2015-03-30 access-url: http://un.is-a-geek.com:8080 2015-03-14 access-url: http://www.baidu.com 2015-02-24 access-url: http://www.teddybrinkofski.com 2015-03-13 Only one of these is valid. Most likely, they're cycling through ranges of addresses to see which listen on port 80, and if open, send dummy HTTP headers to check if the response indicates a server with known security vulnerabilities. I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then just drop the connection. A further refinement would be virtual hosting in which different Host: values map to different repositories. I don't need this feature, but others might. If it's not already clear, this particular repository should only be accessible to a handful of people. Anonymous access is already disabled, but I ought to do SSL to shut out anyone sniffing the network. However, the server uses a 350MHz PII with 256MB RAM, so this might be tight. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Limiting HTTP/1.1 host
On 4/30/2015 12:36 PM, Ron W wrote: On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth andrew.m.g...@gmail.com wrote: Seems I have a lot of people trying to access my repository who have no business doing so: I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com http://un.is-a-geek.com or un.is-a-geek.com http://un.is-a-geek.com. (note final period) then just drop the connection. The HTTP Host header field is the name of targeted server, not the client's host. This field is used to support virtual hosting. I know, and in my original email I went on to say that a refinement of my simple request would be to implement virtual hosting. My point is that any attempt to access my repository other than through one of the few expected hostnames is clearly illegitimate, and I wish to block it. Because this is an application-layer thing, this cannot be done with iptables, only inside the HTTP server. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Limiting HTTP/1.1 host
On 5/1/2015 8:12 PM, Ron W wrote: I somehow got the impression you wanted to limit the sources of incoming requests, thus my idea to limit the addresses from which the requests would be accepted. Nah, usernames and passwords are better for that. I can't know in advance which addresses each user will use. But I do know no legitimate user will send Host: 5.61.43.116 when that's not even my IP address! -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [fossil changes] and execute/symlink flag changes
I propose extending [fossil changes] to report when a file's execute bit has changed or it has become a symlink or ceased to be a symlink. For various annoying reasons, many times I've unwittingly checked in a bunch of execute or symlink brokenness, sometimes not discovering it until much later. Running [fossil changes] before [fossil commit] isn't enough to protect me from this problem. My question is whether this extra level of reporting should be standard [fossil changes] behavior or only accessible if an extra option is supplied. My vote is to make it always report execute bit and symlink state changes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Reporting symlink changes
When a symlink turns into an ordinary file, the Fossil change listing says execute permission cleared. When a symlink is replaced with a file that's also executable, Fossil says execute permission set. When a file becomes a symlink, nothing is said at all. Fossil ought to report symlink changes in addition to content and execute bit changes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Reporting symlink changes
On 5/7/2015 7:33 PM, Andy Goth wrote: When a file becomes a symlink, nothing is said at all. Actually, I'm not entirely sure this is always the case. I have one repository where making a non-executable file into a symlink resulted in execute permisssion cleared but another repository where it gave no change report at all. Maybe it has to do with whether the target file is executable. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Feature idea: Protected branches
On 5/11/2015 9:10 AM, Richard Hipp wrote: On 5/11/15, Abilio Marques abili...@gmail.com wrote: I recall seeing no way of detecting a push to a specific branch. All I saw were deltas and stuff like that. To change Fossil to have the ability to prevent pushes to certain branches, we would have to add knowledge of branches and check-ins to the push/pull logic. Note also that this goes against one of the founding principles of Fossil: that the VCS should implement mechanism not policy. That is to say, details of who should be able to check-in to which branches and whatnot should not be enforced by the VCS. Project policies need to be enforced by some other means. Can TH1/Tcl be used to implement such policies? I wonder if it's possible to tie this to the push/pull logic but rather the commit and tagging logic, such that the prohibition happens as quickly as possible, and the developer isn't in for a surprise when the eventual sync takes place but fails. This leads to a host of questions. Having local access to a cloned repository gives unlimited control, so (unless all committers are trusted) the push/pull logic needs to double-check the rules. Also, there's more than one way to put a commit on a branch, so checks need to be performed against control artifacts as well as normal check-ins. Also I want to draw a comparison to closed branches. Can closed branches be refactored to be implemented in terms of this new facility, or can the closed branch feature itself be expanded to provide the foundation for limiting write access to branches? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Extended commit edit history
Currently, Fossil's info page shows only the original and final (edited) date, user, check-in comment, and tags/properties. Is there any interest in adding an option to show all revisions of the above rather than only the first and last? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Feature idea: Protected branches
On 5/11/2015 11:57 AM, Richard Hipp wrote: On 5/11/15, Andy Goth andrew.m.g...@gmail.com wrote: My wishlist derives from my organization's needs which are currently being met by ClearCase ... My mechanism not policy rule derives from some very bad experiences with ClearCase... I understand completely, and I sympathize. Nevertheless, we have projects where a single repository would contain branches and versions delivered to many different customers, including customers to whom inadvertent disclosure of things meant for other customers would have rather thorny consequences. It's not sufficient to trust that the engineers will never make mistakes or move tags around after having shipped. Of course it's possible (and a very good idea) to externally keep track of the SHA-1 artifact ID of various pertinent check-ins, e.g. in a version description document. But we engineers just want to be able to search for YF21UNAF-TEST-1.03 or whatever, without having to worry that somebody moved the label to sneak a spelling fix past QA. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Feature idea: Protected branches
On 5/11/2015 3:08 PM, Ron W wrote: Another possible work-around (besides what Andy and I suggested) would be for contributing devs to mark their trunks (and other designated protected branches) as private. Then, when working on a feature/fix branch, fossil publish branchname to make that branch push-able. I've considered this, but there are some considerable drawbacks. One, the abandoned versions can be forever lost, even if they may have become eventually useful for reference or future integration if requirements change. Two, this restricts each developer to work from a single repository file, so (depending on how things are set up) they may not be able to access their code if their favorite shared terminal in the lab is occupied one day. That's right, it's not always possible for people to have their own computers at their own desks. I often deal with development on a segregated network, and within that segregated network people are not assigned individual computers. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Feature idea: Protected branches
On 5/11/2015 11:29 AM, Ron W wrote: If the project is too big for re-cloning every time there is an accidental commit to trunk, then you could require the contributing devs to send bundles to the integrator. On import, commits from a bundle have a special status that allows them to be un-imported. This sounds like it could be automated. But whenever something that may be a commonly desired feature can be automated, it ought to be considered for integration (functionally speaking) into Fossil itself. In other words, this is something I've wanted too. :^) -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] empty-dirs parents
I checked in branch andygoth-empty-dirs-parents which causes parents of empty-dirs to be created on update if they don't already exist. Current behavior is to warn if an empty-dirs directory is in a directory that doesn't already exist. Consequently, at the moment it's necessary to explicitly list the parents of all intended empty-dirs in the empty-dirs settings, and to list them in the right order. Somebody please review this branch, let me know if it works for you. I would like to commit to trunk but don't want to unilaterally destabilize things on account of a release coming soon. I prefer to have a partner in crime. :^) -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Feature idea: Protected branches
On 5/12/2015 3:38 PM, Warren Young wrote: The OP said that each of his clients has artifacts in the repository that can’t be shared with other sub-sections of the repository, for unspecified reasons. He also talked about a shared code base. That’s an N+1 situation. Let me make a correction here. I am not the OP. That would be Abilio Marques. I amplified his points to show that there is some interest in a way to add some finer-grained protection to Fossil. In my view, the scripting mechanism may be the way to do it so the specifics of the implementation are given over to the administrator. The unspecified reasons are ITAR regulations and the like. They don't have to make sense because they flow down from government. I would prefer to not discuss them further. drh and I had a private conversation on this subject several years ago. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/8/2015 1:13 PM, Warren Young wrote: On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote: My question is whether this extra level of reporting should be standard [fossil changes] behavior or only accessible if an extra option is supplied. My vote is to make it always report execute bit and symlink state changes. I’m in favor of the idea, but I’ll tell you this up front: I’ll never see the warning unless it appears in either “fossil status” output or in the editor text generated by the interactive form of “fossil checkin”. I don’t use “fossil changes” at all. Deep svn muscle memory keeps me saying “f stat” instead. I made it standard in [fossil changes] and [fossil status]. See commit [03679b58]. Please give it a whirl and let me know if it satisfies. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 12:02 AM, Andy Goth wrote: I made it standard in [fossil changes] and [fossil status]. See commit [03679b58]. Please give it a whirl and let me know if it satisfies. As you may have noticed, I decided to move this change to a branch called andygoth-metadata-changes. The (updated) comment: BUG: [fossil commit] does not reset the chnged flag for files whose contents have not changed, i.e. files whose only change is adding/removing executable/symlink status. Thus the files continue to show as changed. This needs to be fixed, but I am not confident working with the guts of [fossil commit]. I would appreciate if someone who knows more about [fossil commit] took a look at this branch. Here is a repeatable test sequence showing the successes and failures of this branch: $ f init fossil-test.fossil $ mkdir fossil-test $ cd fossil-test $ f open ../fossil-test.fossil $ mkdir .fossil-settings $ echo 1 .fossil-settings/allow-symlinks $ f add .fossil-settings/allow-symlinks $ f commit -m 'allow symlinks' $ echo -n hello normal_to_exec $ echo -n hello normal_to_symlink $ echo -n hello exec_to_normal $ echo -n hello exec_to_symlink $ ln -s hello symlink_to_normal $ ln -s hello symlink_to_exec $ chmod +x exec_to_normal $ chmod +x exec_to_symlink $ f add . $ f commit -m 'add content' $ ln -sf hello exec_to_symlink $ ln -sf hello normal_to_symlink $ rm -f symlink_to_exec symlink_to_normal $ echo -n hello symlink_to_normal $ echo -n hello symlink_to_exec $ chmod -x exec_to_normal $ chmod +x normal_to_exec symlink_to_exec $ f changes UNEXEC exec_to_normal SYMLINKexec_to_symlink EXECUTABLE normal_to_exec SYMLINKnormal_to_symlink EXECUTABLE symlink_to_exec UNLINK symlink_to_normal $ f commit -m 'change metadata' Now we've come to the problem! Running [fossil changes] at this point will result in the same list of changes shown above. Likewise, running [fossil commit] again will succeed despite there not being any actual changes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 10:43 AM, Warren Young wrote: On May 15, 2015, at 9:00 AM, Richard Hipp d...@sqlite.org wrote: The whole purpose of --allow-empty is to force Fossil to do a check-in that deliberately has no changes from the previous check-in. This is done, for example, to tag a release. I can see that that is shorter than “fossil tag add”, but it nets out to about the same number of keystrokes, since the artifact ID needed with “tag add” is within easy reach of a copy-paste. I find it best to tag the release with “ci --tag” when checking in the file that holds the version number. That checkin updates the ChangeLog, too, if there is one. I only resort to “tag add” when I forget to do this. drh's preference seems to be to make an additional check-in highlighting the release. I imagine the reason he does this is so that the comment can simply say something like Version 3.8.10.1, rather than describing the changes that went into it, since there are none. You're obviously free to instead apply the release tag to the final change. Some people also do it to start a new branch. As above, --allow-empty is also unnecessary for this, since we still have “f ci --branch”. I'm not sure you understand drh's point. He's once again saying that some people like to highlight special events (citing release and branch creation) as check-ins containing no actual changes. This gives Fossil users a space to describe the milestone. Of course Fossil also provides technotes née events, but technotes aren't tied to a version or branch and can't have tags and all that. I suppose technotes describe the project as a whole rather than a particular version, release, or branch. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 10:46 AM, Warren Young wrote: On May 14, 2015, at 11:02 PM, Andy Goth andrew.m.g...@gmail.com wrote: Please give it a whirl and let me know if it satisfies. I just tried 1.33 [209da9bced] on a Linux box, and neither “chmod +x existing-text-file” nor “chmod -x bin/existing-script results in a noted change in “fossil status”. I thought that was the purpose of this change. “fossil revert existing-file” does put the executable bit back to its prior state, so Fossil does know the correct value. That is all expected behavior. I decided to move the change to a branch, and 209da does NOT include the change. Right now I am writing an email describing the problems with it and giving a test case. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 12:02 AM, Andy Goth wrote: On 5/8/2015 1:13 PM, Warren Young wrote: On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote: My question is whether this extra level of reporting should be standard [fossil changes] behavior or only accessible if an extra option is supplied. My vote is to make it always report execute bit and symlink state changes. I’m in favor of the idea, but I’ll tell you this up front: I’ll never see the warning unless it appears in either “fossil status” output or in the editor text generated by the interactive form of “fossil checkin”. I don’t use “fossil changes” at all. Deep svn muscle memory keeps me saying “f stat” instead. I made it standard in [fossil changes] and [fossil status]. See commit [03679b58]. Please give it a whirl and let me know if it satisfies. Discovered a side effect. This reduces the need for the -allow-empty option to [fossil commit] since it is now aware of execute and symlink changes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 12:52 PM, Andy Goth wrote: This problem appears to be fixed. Please see andygoth-metadata-changes if works for you. Repeating the test case from the previous email (repeated below) gives a good result with no changes shown after the final commit. $ f version This is fossil version 1.33 [076c854482] 2015-05-15 17:10:48 UTC Correction. This was done with version [9e52251e6e]. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Is this a fork?
On 5/17/2015 7:16 PM, jungle Boogie wrote: On 10 May 2015 at 12:38, jungle Boogie jungleboog...@gmail.com wrote: Hello All, http://www.fossil-scm.org/index.html/timeline.rss More fork examples exist in the timeline: http://www.fossil-scm.org/index.html/timeline.rss 05/17/2015 01:45 PM *FORK* Rework [b824b3e7f7] to ensure the [diff] link or the actual inline diff is inside the paragraph block. 05/17/2015 02:54 PM *FORK* Correct spelling of the word literal. 05/16/2015 10:54 PM *FORK* Consistently use periods and end-paragraph tags in append_file_change_line(). How very odd. These can't possibly be forks since all this work was done by me out of a single repository, and no one else was committing during this time. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] andygoth-user-reports
On 5/17/2015 11:22 PM, jungle Boogie wrote: This holds true for the first nine, but what about that src/sqlite3.c file, which would be this page: https://www.fossil-scm.org/index.html/finfo?name=src/sqlite3.c I don't see any check-ins for user andybradford using Firefox's find. But there I do: https://www.fossil-scm.org/index.html/timeline?n=200y=civ=1c=2015-03-21+23%3A34%3A57nd=u=andybradford I don't think this is any kind of bug but there may be confusion as why a committer is showing up for a file but you can't find any check-ins in the finfo page for that user. This is indeed a bug. See this email for analysis and another symptom: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20586.html FWIW, I like the work you're doing! Thanks. You're welcome. At the moment I can't get to the work I'm supposed to be doing, so I decided to hack Fossil instead. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Incorrect check-in count on file report
Test case: f init x.fossil mkdir x cd x f open ../x.fossil touch file1 file2 f add * f commit -m 1 echo hello file2 f commit -branch branch -m 2 f up trunk echo hello2 file1 f commit -m 3 f merge -integrate branch f commit -m 4 Now the /reports?view=byfile page shows file1 and file2 as having three check-ins each. This is clearly incorrect. It's not 100% clear how this is intended to be measured for file2, but for file1 there were definitely only two check-ins. This is a bug in need of fixing, and (other than the next paragraph) the rest of this email deals with it. file2 is in a gray area. It appears in three check-ins, but the last such check-in was a merge in which the branch version was pulled onto trunk without further modification. How do we want to count this? Now, to explore the bug... will start over and take this step by step. f init x.fossil mkdir x cd x f open ../x.fossil touch file1 file2 f add * f commit -m ci-1 -tag ci-1 echo hello file2 f commit -m ci-2 -tag c1-2 echo there file2 f commit -m ci-3 -tag ci-3 echo hello file3 f add file3 f commit -m ci-4 -tag ci-4 At this point, /reports?view=byfile shows: - file1: 1 check-in - file2: 3 check-ins - file3: 1 check-in This is correct. Let's continue... f up ci-1 echo hello file1 f commit -branch br-1 -m ci-5 -tag ci-5 Now the by-file report shows: - file1: 2 check-ins - file2: 3 check-ins - file3: 1 check-in Also good. f up trunk f merge br-1 f commit -m ci-6 -tag ci-6 Now the by-file report shows: - file1: 3 check-ins - file2: 4 check-ins - file3: 2 check-ins Uh oh. file1's count was incremented, which is good. But so was the count of every file that had been modified between br-1's baseline and merge, which is bad. What's wrong? Let's have a look at the repository database. Rewind history, and at each point where I showed the by-file report, I'll show you the database, using sqlite3 -column -header ../x.fossil and this query: SELECT name, mid, comment FROM filename NATURAL JOIN mlink, event WHERE mlink.mid = event.objid ORDER BY name; Immediately after f commit -m ci-4 -tag ci-4... namemid comment -- -- -- file1 3 ci-1 file2 3 ci-1 file2 5 ci-2 file2 7 ci-3 file3 8 ci-4 Immediately after f commit -branch br-1 -m ci-5 -tag ci-5... namemid comment -- -- -- file1 3 ci-1 file1 9 ci-5 file2 3 ci-1 file2 5 ci-2 file2 7 ci-3 file3 8 ci-4 And now the naughty. Following f commit -m ci-6 -tag ci-6... namemid comment -- -- -- file1 3 ci-1 file1 9 ci-5 file1 10 ci-6 file2 3 ci-1 file2 5 ci-2 file2 7 ci-3 file2 10 ci-6 file3 8 ci-4 file3 10 ci-6 The problem is all those mid=10 comment=ci-6 rows. There should be only one for file1, but file2 and file3 are also linked to ci-6, i.e. the fatal merge. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-user-reports
The andygoth-user-reports branch does a ton of cleanup in the reports page, mostly to the way users are handled. The weekday and file reports didn't even support user filtering at all. I also added the ability to type the user name directly rather than having to find it in the users report then go to the report actually desired. In addition, I fixed the type selection links to not lose the user. Please give andygoth-user-reports a whirl and report any positive or negative impressions or experiences. In the process of testing the user filtering on files, I noticed the file change counts are wrong. I documented this in another email. The problem is not fixed yet, and I suspect the correction, whatever it is, won't take effect until the next rebuild. I hope no one minds me spamming everyone with new code. :^) It's pretty much all on branches so we will have the ability to decide what does and does not make it into the next release. Though I must say that I'm coding up the stuff I would like to be in the next release. Not up to me though. I'm just writing code to scratch itches and learn more about the Fossil guts. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-tkt-674d5d5556
By request from jungle Boogie, I attempted to fix ticket 674d5d5556 The timeline does not filter by an unexisting tag. My proposed fix is on branch andygoth-tkt-674d5d5556. It works for me, but I invite outside testing before merging to trunk. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Mystery user!
https://www.fossil-scm.org/index.html/reports?view=byuser Sorted by event count, the user between viriketo and ron has empty string for a name. What's going on here? Is this bug, or is it some legacy from the early days of Fossil? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] andygoth-user-reports
Yeah, I first saw the issue when using the file report, filtered by user (new feature on this branch), to see what all files I've ever touched. I saw a great many I'd never have expected, and they're not actually included in the changed file listings of any of my commits. I don't think it makes sense to attribute to me changes to files that were done by others just because I merged after them. On May 18, 2015 6:52 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said jungle Boogie on Mon, 18 May 2015 10:45:54 -0700: Got it, cool. Thanks for the clarification! Perhaps... Andy Goth actually thinks the behavior is a bug and provided a link to some steps to cause the behavior. I'm not sure without further investigation. Andy -- TAI64 timestamp: 4000555a7b4e ___ 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] andygoth-inhibit-deleted-wiki-link
In a check-in comment, putting arbitrary text in brackets does not mean to create a wiki page. That is a major difference between check-in comments and wiki pages, even when wiki-formatted check-in comments are enabled. On May 18, 2015 4:19 PM, Ron W ronw.m...@gmail.com wrote: On Sun, May 17, 2015 at 3:42 PM, Andy Goth andrew.m.g...@gmail.com wrote: I just checked in something that's been lurking in my stash since April of last year. It inhibits links from check-in comments to deleted/empty wiki pages. In the context of a commit comment, it does make sense despite the very common Wiki convention that a link to a non-existent Wiki page be a means to create a page with that name. Is this behavior what you are trying to avoid? ___ 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] Feature idea: Protected branches
On 5/12/2015 9:23 PM, Richard Hipp wrote: On 5/12/15, Ron W ronw.m...@gmail.com wrote: On the other hand, if [you] require such strict controls, a DVCS, whether Fossil, Git or other, is likely not the tool you need. So the only way for the central repo to enforce strict controls is to carefully analyze content it receives via push and reject non-conforming content. This is difficult to implement and maintain. It also leads to a situation where the content in the developers repo does not exactly match the central copy because some of the content was rejected. And it seems like inconsistencies between developer copies and official copies is something that you should be zealous to avoid. It seems reasonable to me to use (new?) scripting hooks to specify constraints to be validated by the client on commit and again by the server on push/pull. This way the developer is informed as soon as possible when there is a problem, even during disconnected operation, and the local repository is not put into a disallowed state. But if the commit constraints are somehow compromised (doesn't even have to be malicious, may simply be due to a policy change that hasn't sync'ed out yet), the nonconforming artifacts are still not permitted to propagate. Obviously the latter is a failsafe, not the first line of defense, and when invoked it means the developer now has to fix the local repository or face errors on every future sync. Though this isn't much different than a user not having push privileges yet making changes to the local repository anyway. That said, I've been toying with ideas of a hybrid centralized/distributed VCS that tries to offer the best of both worlds - disconnected operation for availability but also close coupling to the central repo with the opportunity to enforce policy. How does the above relate to your thoughts? (1) Assume that developers (people with push privilege) are not malicious and will usually follow the rules. (Such assumptions are *not* made about users with less privilege, such as random passers-by on the internet, obviously.) This is not a bad assumption to make. If we can only have part of what I described above, I'd take the client-side on-commit constraints rather than the server-side on-push constraints. This covers everything but malice and unsynced policy changes, which all should be vanishingly rare in the kind of professional environment where any of this matters in the first place. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Timeline regression in c0c0bae7
http://www.fossil-scm.org/index.html/info/c0c0bae719eb96e6 This check-in introduced a regression in the timeline when there are d, p, or dp query parameters used in combination with the r parameter. Such a query is constructed by branch changes. For example, this artifact: http://www.fossil-scm.org/index.html/info/de879859644fac48 links here via the new branch name: http://www.fossil-scm.org/index.html/timeline?r=andygoth-brackets-outside-linknddp=a2020a7ac8b6db24unhide which gives a timeline that says of [a2020a7a] and nothing else. Prior to the check-in I identified in the first line of this email, said link would give artifacts related to the branch and surrounding the check-in being amended. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-brackets-outside-link
The andygoth-brackets-outside-link branch moves all square brackets outside of a.../a links, so instead of a[1234]/a, you get [a1234/a]. The motivation is to make it easier to copy-and-paste artifact IDs from typical web browsers, which do not permit using the mouse to start a selection in the middle of a hyperlink. Another consequence is the brackets have a different visual style than the artifact IDs and other link text. I like it better this way because it shows that the brackets are not part of the artifact ID. For consistency, I did this absolutely everywhere, not just with artifact IDs. Please review and let me know what you think. This was originally discussed a year ago and three days ago. Glad to finally have gotten around to it. http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg15682.html -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-inhibit-deleted-wiki-link
I just checked in something that's been lurking in my stash since April of last year. It inhibits links from check-in comments to deleted/empty wiki pages. See the andygoth-inhibit-deleted-wiki-link branch. f new x.fossil mkdir x cd x f open ../x.fossil f server echo 'this is a test' | f wiki create hello f commit -allow-empty -m 'link to page [hello]' f wiki commit hello /dev/null Prior to executing the final fossil wiki commit command, the timeline shows [hello] as a link to the wiki page. With my change, after doing the final command which deletes the page, the word [hello] in the timeline reverts back to being plain text, as if the wiki page had never been created. What does everyone think of this change? Is it worth merging to trunk? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Showing file type changes in /info
Please review branch andygoth-metata-info which better shows file type changes (regular, executable, symlink) in the /info page. Currently, the /info page only shows when a file becomes or ceases to be executable, with no support for symlinks other than to confusingly say that they've lost their execute permission. My new code also takes the opportunity to link to the contents of the file. I experimented with showing the symlink target directly, linking to the target file, but it's too much work (for now) to grovel through subdirectories and dangling symlinks. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Showing file type changes in /info
On 5/15/2015 1:33 PM, Andy Goth wrote: Please review branch andygoth-metata-info which better shows file type changes (regular, executable, symlink) in the /info page. I meant andygoth-metadata-info. Ugh, I can't get anything right today. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 11:01 AM, Andy Goth wrote: As you may have noticed, I decided to move this change to a branch called andygoth-metadata-changes. The (updated) comment: BUG: [fossil commit] does not reset the chnged flag for files whose contents have not changed, i.e. files whose only change is adding/removing executable/symlink status. Thus the files continue to show as changed. This needs to be fixed, but I am not confident working with the guts of [fossil commit]. I would appreciate if someone who knows more about [fossil commit] took a look at this branch. No one having stepped forward, I gave it a harder look. The BUG description I gave was wrong. [fossil commit] indeed reset chnged, but it did not update isexe or islink so the file showed as having changed metadata the next time changes were checked. Now we've come to the problem! Running [fossil changes] at this point will result in the same list of changes shown above. Likewise, running [fossil commit] again will succeed despite there not being any actual changes. This problem appears to be fixed. Please see andygoth-metadata-changes if works for you. Repeating the test case from the previous email (repeated below) gives a good result with no changes shown after the final commit. $ f version This is fossil version 1.33 [076c854482] 2015-05-15 17:10:48 UTC $ f init test.fossil $ mkdir test $ cd test $ f open ../test.fossil $ mkdir .settings $ echo 1 .fossil-settings/allow-symlinks $ f add .fossil-settings/allow-symlinks $ f commit -m 'allow symlinks' $ echo -n hello normal_to_exec $ echo -n hello normal_to_symlink $ echo -n hello exec_to_normal $ echo -n hello exec_to_symlink $ ln -s hello symlink_to_normal $ ln -s hello symlink_to_exec $ chmod +x exec_to_normal $ chmod +x exec_to_symlink $ f add . $ f commit -m 'add content' $ ln -sf hello exec_to_symlink $ ln -sf hello normal_to_symlink $ rm -f symlink_to_exec symlink_to_normal $ echo -n hello symlink_to_normal $ echo -n hello symlink_to_exec $ chmod -x exec_to_normal $ chmod +x normal_to_exec symlink_to_exec $ f changes UNEXEC exec_to_normal SYMLINKexec_to_symlink EXECUTABLE normal_to_exec SYMLINKnormal_to_symlink EXECUTABLE symlink_to_exec UNLINK symlink_to_normal $ f commit -m 'change metadata' $ f changes -v (none) If everyone is good with this, I'll merge it to trunk. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [fossil changes] and execute/symlink flag changes
On 5/15/2015 12:52 PM, Andy Goth wrote: $ mkdir .settings Correction #2. I meant .fossil-settings. Argh! Sorry for spamming the list. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Symlink trouble
On 4/8/2015 2:44 PM, David Mason wrote: Here is another problem with symlinks: [add files in a subdirectory] [commit] [move subdirectory outside of repository] [create symlink to subdirectory with same name as original] [Fossil doesn't notice anything happened] Same problem if you move the directory into a nested working directory. Continuing from the previous example (hence the first couple of commands to revert to the original situation): Fossil operates on files, not directories. If it can stat all the files and they all have the same contents as in the repository, it doesn't realize there's a change. You don't even need directories for this: $ f new tmp.fossil $ mkdir tmp $ cd tmp $ f open ../tmp.fossil $ f settings allow-symlinks 1 $ echo hello a $ echo hello b $ f addremove $ f commit -m 1 $ ln -sf a b $ f changes (shows nothing) $ f commit -m 2 (complains that nothing has changed) $ echo goodbye a $ f changes (shows both a and b as having been edited) $ f commit -m 2 $ f artifact current (shows a and b are files with the same checksum) I tossed in an allow-symlinks just to show that this bug is there even when symlinks are explicitly enabled. Removing the allow-symlinks line gives the same failure. To fix (assuming we want to go down this rabbit hole), we must teach Fossil more about where symlinks may lurk. Each path component (subdirectories and files) could be a symlink and must be checked. It's not enough to blindly open files and read their contents. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Symlink trouble
On 4/9/2015 12:00 PM, David Mason wrote: I use symlinks a lot. I *really* wish fossil handled them properly. This is one of my biggest beefs about fossil. Fossil's driving requirement is to support the development of SQLite, and its applicability anywhere else is just a bonus. Since SQLite does not require symlinks, it is unsurprising that Fossil did not originally support symlinks. Symlink support was added by Dmitry Chestnykh in 2011, done to his satisfaction. It's only natural as time progresses that other users with other use cases flush out omissions in the initial symlink implementation, just like with anything else. In this thread we have identified a few such shortcomings, and it makes sense that we fix them, provided we do so in a way that does not interfere with Fossil's driving requirement. The other big one is that if I set some property (in this case allow-symlinks true) and I also set the corresponding .fossil-setting I get a warning when I do almost anything. I keep intending to do something about these annoyances, but never find the time. I know where and how to fix this warning such that it only shows in the case of discrepancy. You can also look at the andygoth-versioned-open branch to see where the code is, since it's adjacent my largest change. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Symlink trouble
My naïve user expectation is checking in .fossil-settings/allow-symlinks with contents 1 is all I need to do to get symlinks to work in a Fossil repository. It does make it possible to check in symlinks. However, it doesn't help when opening a new checkout. In this situation, symlinks are created as ordinary files containing the link target, just like on Windows. The problem is db_open_repository() uses db_get_boolean() to get the value of allow-symlinks. db_get_boolean() uses db_get() uses db_get_versioned() uses blob_read_from_file() which reads on-disk files. Of course, on-disk files don't exist until after the checkout is opened, so no versioned settings can be read right at the start of db_open_repository(). By the time it's possible to read the versioned settings, it's too late, and the symlinks have already been demoted to normal files. Things get really nasty when the symlinks point to executable files. Performing a commit after the open demoted the symlinks now results in execute permission cleared changes, and the new manifest records that the former symlinks are now just non-executable files. db_get_versioned() bails out if !g.localOpen since it knows it's not going to be able to read the files anyway. But instead of bailing out when not open, I think it would be better for it to pull the value out of the repository instead of an on-disk file, analogous to: fossil cat -R repo.fossil .fossil-settings/allow-symlinks My andygoth-versioned-open branch (just checked in) addresses this problem and seems to fix the symlink issue. However, the Fossil coding style is rather alien to me, particularly the way it leaks memory on purpose, so the way I'm doing things may not be the best. Please have a look, and feel free to ask questions and make suggestions and further changes. Test case: f new test.fossil mkdir -p test/.fossil-settings cd test f open ../test.fossil echo 1 .fossil-settings/allow-symlinks ln -s asdf fdsa f addremove -dotfiles f commit -m test f close cd .. rm -rf test mkdir test cd test f open ../test.fossil ls -l fdsa should show a symlink, not a regular file. See also: https://groups.google.com/forum/#!topic/fossil-users/L6yrc2cQfGE -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Symlink trouble
On 4/8/2015 12:15 AM, Andy Goth wrote: My naïve user expectation is checking in .fossil-settings/allow-symlinks with contents 1 is all I need to do to get symlinks to work in a Fossil repository. It does make it possible to check in symlinks. However, it doesn't help when opening a new checkout. In this situation, symlinks are created as ordinary files containing the link target, just like on Windows. Oh, forgot to mention that everything works just fine if you don't use versioned settings and instead use the [fossil settings] command directly. However, this is inconvenient because every user of a repository has to run the same command. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Interpretation as control artifact
The function sterilize_manifest() in manifest.c has me puzzled. It adds a line of junk to the end of a manifest to create a file that can't be interpreted as a control artifact if checked into another repository. My question is whether or not this can ever actually be a problem, or if this function is a holdover from an older version of Fossil that was susceptible to confusion. At heart, a Fossil repository is a collection of artifacts, but there's no metadata other than embedded in the way the artifacts reference each other. So how does Fossil know which artifacts to interpret as control artifacts? It can test each to see if it fits the manifest schema, and that's what sterilize_manifest() is intended to thwart. But it's theoretically possible to check in a file whose contents resembles a manifest. Is this a fundamental limitation of Fossil? During reconstruct it has only the artifacts to go by, so yes I would guess it runs the risk of treating manifest lookalikes as check-ins. What's the real story here? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Symlink trouble
On 4/8/2015 1:14 AM, Joe Mistachkin wrote: I've made some tweaks on the branch. Thank you, I appreciate it. I hesitated to do much more than move existing code around since I don't know how strong the stylistic preferences are. For example, one thing I wanted to do was treat pointers as booleans, e.g. if(pointer) rather than if(pointer!=0), but the precedent seemed to go against me. I'd like to do refactoring but really don't want to step on toes, especially regarding the memory leak policy: we're already relying on the ultimate garbage collector. Penultimate I mean, since power failure is the ultimate. :^) Here are the highlights: 1. By changing the return code checking for historical_version_of_file(), which apparently returns greater than zero on success. I'm pretty sure it returns its final argument if there's a failure, or panics on failure if its final argument is zero. So it should be sufficient to check if its return value doesn't match its final argument. However, it's not clear what it returns on success (you say greater than zero, but you also say apparently suggesting you don't know the full specification). In my tests I found it returned 1, so when its final argument was 1 it was impossible to distinguish between success and failure. So I went with -1 as the final argument. Sorry, not going to dig into the code just this second, so I don't recall what the names of the parameters. 2. Set noWarn based on the historical version of that file, if it exists. I thought about doing this but figured it didn't matter all that much for the open operation, but I will gladly accept your enhancement. 3. Unrelated: Removed superfluous slash in the .fossil-settings path used by print_setting(). Baseline issue, but again thanks. Also I recall you made it not try to update the cached value of allow-symlinks if there aren't any check-ins in the repository. This is fine, though now that we're forcing the initial empty check-in again, I'm not sure of the benefit. Maybe you're just dodging a NULL dereference in the case of a repository made with an older Fossil. Or maybe you could shun the initial empty check-in and rebuild, but the rebuild might make another initial empty check-in. Not sure, but still this is a good check to add. -- Andy Goth | andrew.m.goth/at/gmail/dot/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] Symlink trouble
On 4/8/2015 1:33 AM, bch wrote: I don't know if it's just me, or if there's a school of thought regarding this, but if this is a case of maintaining symlinks to publish as part of a distribution, I usually relegate their management to a script that will be part of a release generation process (with repository != release in mind). Are the problematic uses of symlinks different from that? I prefer your approach, however I did not get to pick in this instance since I am trying to import an existing repository from ClearCase, actually a snapshot, and it uses symlinks. Furthermore I think some of the symlinks are used stupidly, but once again I don't get to pick. -- Andy Goth | andrew.m.goth/at/gmail/dot/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] Symlink trouble
(email to reporter of problem several years ago, copying list so discussion can continue here) I made a fix to Fossil opening a repository containing symlinks. It's currently on a branch. For details, see this thread: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20112.html And here's code: http://www.fossil-scm.org/index.html/timeline?r=andygoth-versioned-open -- Andy Goth | andrew.m.goth/at/gmail/dot/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] Renames and multiple merges
On 6/4/2015 12:44 PM, Andy Goth wrote: On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): [see http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html] My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. Looking at the merge code, I see this comment: ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. Thinking about this further, it's making more and more sense. The merge algorithm of working from the nearest common ancestor is built on the assumption that everything before then has already been merged. That assumption does not hold in the situation given by the second sentence of the comment quoted above. I imagine the solution is to have separate common ancestors for file data and file names. For file data, the current algorithm is good: use the nearest common ancestor. But for file names, since name changes aren't always incorporated into the merge, pick the common ancestor only by looking at predecessors, without regard to merge cards. I'm not sure how to adapt this to the existing code. More thought is needed. Maybe it's as simple as passing a different pid value to find_filename_changes() in merge_cmd(), but I have a hard time believing this won't choke on more complex cases. Also pivot_find() would need to be changed to take an argument instructing it to honor or ignore past merges, and I don't feel I understand the database well enough to do that. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Renames and multiple merges
On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): [see http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html] My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. Looking at the merge code, I see this comment: ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. In the first case (the successful merge), the rename is on P-V only. The file is named a in both P and M but renamed b in V. In the second case (the failed merge), there are no renames. P and M have a file named a, and V has an apparently unrelated file named b. Here's the output of the first merge, rerun with -v and -debug: merge-from: [9af3457a2e] by andy on 2015-06-04 17:37:36 2 (trunk) baseline: [16309abd54] by andy on 2015-06-04 17:37:36 1 (trunk) P=3 16309abd543dd0e8e4315a357e3ec0eea4bb7986 M=6 9af3457a2e67f1128c1c72afbe78221fc0915e8d V=4 86e3dedd7a825e861797522a61009ee45a014e10 P-V at 4 86e3dedd7a: 1[a] - 0[] P-V at 4 86e3dedd7a: 1[a] - 2[b] P-V summary 1[a] - 2[b] 1: ridv=2ridp=2ridm=5chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [b] fnp = [a] fnm = [a] UPDATE b And the second merge, which fails to update b: merge-from: [35b5f2f6ed] by andy on 2015-06-04 17:40:08 3 (trunk) baseline: [5d7b980414] by andy on 2015-06-04 17:40:08 2 (trunk) P=6 5d7b980414c124cea1ac5d196528dd0be6a64610 M=9 35b5f2f6ed36d6819e6f545999b0ffb989afc937 V=7 1934161b59531bd188a9ad34201f01328859e800 1: ridv=5ridp=0ridm=0chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [b] fnp = [b] fnm = [b] 2: ridv=0ridp=5ridm=8chnged=0 isexe=0 islinkv=0 islinkm=0 fn = [a] fnp = [a] fnm = [a] -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] [OT] command line help and question marks for oprtional arguments
Fossil has Tcl heritage through SQLite, also TH1, so it makes sense that this convention carry through by habit. I believe very very old Tcl used square brackets in its documentation to indicate optional arguments, but it quickly switched to question marks to avoid ambiguity with script substitutions which are done using square brackets. On Jun 4, 2015 1:30 AM, Luca Ferrari fluca1...@infinito.it wrote: Hello, one thing that puzzles me every time I do fossil command help is the presence of question marks for oprtional parameters, as in % fossil help commit Usage: fossil commit ?OPTIONS? ?FILE...? while I would expect it to be like % fossil help commit Usage: fossil commit [OPTIONS] [FILE...] Now, if I get it right the fossil syntax comes from the one used in tcl, or at least is what I can see in tclsh(1). Is this right? Is there a particular rationale for this (and any pointer to the name/conventions of such syntax)? Thanks, Luca ___ 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] Renames and multiple merges
After renaming files on a branch, it seems Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): f new merge-rename.fossil mkdir merge-rename cd merge-rename f open ../merge-rename.fossil echo hello a f add a f commit -m 1 f mv -hard a b f commit -branch branch -m 1.1.1 f up trunk echo goodbye a f commit -m 2 f up branch f merge trunk f commit -m 1.1.2 f up trunk echo broken a f commit -m 3 f up branch f merge trunk Everything is good until the final command, which only adds a MERGED_WITH record to the checkout but does not actually change any files. My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. This is causing major trouble for me since I have a branch in which everything was renamed to support a reorganization effort, yet I need to continue merging stuff from trunk which doesn't have the renames. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] NOT_A_FILE problem
On 6/5/2015 7:30 AM, Jan Danielsson wrote: I always make sure there aren't any contradictions in a commit (i.e. remove file X, and X is also a directory in the same commit). Perhaps off-topic, but I see no reason why you should have to worry about this particular case. Fossil does not track directories, only files. The name of a file includes its full path, but you could also have used _ or some other such character to arrange your files in a hierarchy, and Fossil wouldn't much care. There's no problem deleting a file called hello and creating one called hello_world, so likewise there's no problem deleting a file called hello whilst creating a file called hello/world. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Renames and multiple merges
On 6/4/2015 7:33 PM, Andy Goth wrote: On 6/4/2015 12:44 PM, Andy Goth wrote: On 6/3/2015 8:27 PM, Andy Goth wrote: After renaming files on a branch, Fossil will allow you only one successful merge until it loses track of which files are which. Here's a sequence showing the problem (version 3ffb6a3e62): http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html My theory is that Fossil doesn't know about the renames if they happened before the nearest common ancestor. ** Rename files that have taken a rename on P-M but which keep the same ** name on P-V. If a file is renamed on P-V only or on both P-V and ** P-M then we retain the V name of the file. The merge algorithm of working from the nearest common ancestor is built on the assumption that everything before then has already been merged. That assumption does not hold in the situation given by the second sentence of the comment quoted above. Does anyone have any thoughts on this? This is still a major problem for me. Merging of renamed files does not work at all when the renames happened on the merged-into branch but before the most recent merge. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil undo for fossil clean
Is there any interest in making fossil clean be an undoable operation? If fossil revert is undoable, why not fossil clean? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] andygoth-help-option
A few weeks ago I was trying to read up on the new -x option to clean. I had started by typing fossil clean -x then decided I wanted help, so I wound up entering fossil clean -x -help, with this result: $ fossil clean -x -help 3-way-mergeco http scrub user artifact configuration leaves search whatis cache dbstat md5sum server wiki cgideconstructnewsha1sumzip checkout descendantsreconstructtarball ci forget redo ticket close fts-config rename unset My command was interpreted as fossil help clean -x which is the same as fossil help -x. On the andygoth-help-option branch, I fixed the -help handler to be careful not to pass along any -options when it can find one argument that is not an option, like so: $ ./fossil clean -x -help Usage: ./fossil clean ?OPTIONS? ?PATH ...? Delete all extra files in the source tree. Extra files are files that are not officially part of the checkout. This operation cannot be undone. If one or more PATH arguments appear, then only the files named, or files contained with directories named, will be removed. If it can't find any non-option arguments (i.e. arguments starting with at least one - character), the prior implementation is used: $ ./fossil -x -help 3-way-mergeco http scrub user artifact configuration leaves search whatis cache dbstat md5sum server wiki cgideconstructnewsha1sumzip checkout descendantsreconstructtarball ci forget redo ticket close fts-config rename unset Any questions or comments? Please review. I'll merge to trunk if no one objects in the next few days. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] fossil undo for fossil clean
On 6/26/2015 9:39 AM, Jan Nijtmans wrote: 2015-06-26 6:31 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: Is there any interest in making fossil clean be an undoable operation? If fossil revert is undoable, why not fossil clean? I already implemented that, feel free to experiment with it: http://fossil-scm.org/index.html/timeline?r=undo-clean Thanks, that's an excellent starting point. I took the liberty of merging trunk into your branch. It compiles, runs, and seems to work. Side note. The only merge conflict (there were two) that had me scratching my head was due to an end-of-line whitespace difference. In Vim I diff'ed the merge (trunk) and baseline (common ancestor) versions, and it highlighted the space character at the end of one of the baseline lines. Has anyone thought about giving fossil merge -w and -Z options like fossil diff has? The problem is that this function might make the _FOSSIL_/.fslckout file much much bigger, e.g. when a lot of built files are cleaned. This can be improved by handling the following files differently: 1) files matching glob-ignore, those will be removed without the possibility to recover. 2) files 10M (is this a good value?), those will be prompted for, before removing them forever. I never really needed that, therefore I didn't do enough with it to thrust it for 100%. But if it's usefull to you, I'm happy about that. I was a bit surprised that you explicitly make the -f option inhibit undo. I would have done otherwise. For a moment I considered saying that it shouldn't matter that the .fslckout file grow huge because its size increase is matched by a decrease in the size of the rest of the checkout. But then I realized that if the cleaned files are generated files, they're likely to be regenerated very soon, so the checkout will grow again while .fslckout remains the same. Following that reasoning, it indeed makes sense to not save backups cleaned ignore-glob files. But take another step and recall that the clean command also honors ignore-glob and will not delete them, sort of -verily or -x. Which implies -f. Which you explicitly do not support. As for the size limit, you present one option: confirming whether or not to back up files larger than ten megabytes. A refinement would be to make this threshold a setting. Or I think the setting could be an overall size limit on the undo backup, so having ten million one-byte files would also prompt. Or allow the user to pick both per-file and overall limits on the theory that huge files are often not worth saving (could be re-downloaded or regenerated since they're rarely made by hand... well maybe they could be user-created photos or videos...), but also large collections of comparatively small object files are also not worth saving. In my opinion, the previous paragraph is merely a failsafe against the case of the user not correctly setting ignore-glob. No conclusions, just getting some thoughts in writing. Will revisit when I have time. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] fossil serve repolist error
On 6/26/2015 5:59 AM, Remco Schoen wrote: I'm trying to host a directory with multiple fossils, but when I want to list the available repositories, I get this error: SQLITE_ERROR: no such table: config Database Error no such table: config SELECT value FROM config WHERE name='allow-symlinks' I occasionally have the same issue, and it is indeed due to the presence of a .fossil file which is incorrectly being treated as a repository. For me, the problem happens because I created a user named fossil whose home directory contains all the repositories being served. (This makes the ssh: URI easy.) For administrative purposes, I occasionally log in as fossil, and sometimes I run fossil commands, forgetting that this has the side effect of making a .fossil file containing global settings and the repository list used by the fossil all subcommands. My fix is always to delete the unnecessary .fossil file. User fossil doesn't do any development, anyway. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] clones taking 2x (or more?) time due to extra delta compression
On 6/26/2015 5:52 PM, Matt Welland wrote: but I don't see any way to turn it off. clone_cmd() unconditionally calls extra_deltification(). There is no way to make it not do this. Probably there should be. also it looks like fossil has low tolerance for parallel running open process. I guess I naively assumed that since sqlite3 is mostly ACID compliant that parallel opening of fossils would be supported. I'm adding locking as a work-around but would the developers be interested or open to adding some resilience to parallel fossil opens? I vaguely recall there being a post to this list saying there's an environment variable that can be set to make Fossil not get an exclusive lock on the repository, but I can't find the post now. What's the truth of the matter? -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] getting rid of warning can't open /dev/null...
On 5/26/2015 3:02 PM, Richard Hipp wrote: On 5/26/15, Will Parsons varro@nodomain.invalid wrote: On Tuesday, 26 May 2015 3:20 PM -0400, Richard Hipp wrote: I think the best solution is to actually create a /dev/null and /dev/urandom inside of your chroot jail. (That's what the www.fossil-scm.org website does.) Unfortunately, I have no idea how to that. mkdir /jail/dev mknod /jail/dev/null c 1 3 mknod /jail/dev/urandom c 1 9 While you're at it, you may optionally do: mkdir /jail/etc cp /etc/localtime /jail/etc so your timeline isn't locked to UTC. You will also need to use the web administration interface to configure the timeline to show in local time. This should be documented on the Fossil website someplace Yes, please. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Joke about Spın̈al Tap
My check-in comment for [6cd7087a] contains a joke about Spın̈al Tap. This is intentional though can be removed now. It was a test to see if I could put such bizarre characters in my comment from the terminal and if Fossil would handle them correctly. It does. However, Firefox's View Page Source feature does not. I have reported the bug here https://bugzilla.mozilla.org/show_bug.cgi?id=1179073 if anyone cares. So my little joke bore some fruit. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] Joke about Spın̈al Tap
On 7/1/2015 2:09 AM, Martijn Coppoolse wrote: On 1-7-2015 3:40, Andy Goth wrote: However, Firefox's View Page Source feature does not. I have reported the bug here https://bugzilla.mozilla.org/show_bug.cgi?id=1179073 if anyone cares. So my little joke bore some fruit. Expect the bug to be closed: it's a font problem, not a Firefox one. It can be both. I tried several different viewers, and results varied. As expected, Thunderbird has the same problem. Notepad showed the diaeresis floating in space between the n and the a. And Vim rendered it correctly! So perhaps it's not so much a font bug as it is a deficiency in the way Firefox handles Courier New missing a character or some such. Attached is a screenshot of the bug page's title in Google Chrome, after changing the title's font to 'Courier New'. Thanks. Also, I've set the font for Firefox's Source view to 'Consolas', and that renders just fine. I repeated your tests here and got the same results. This is off-topic for the list, so I will move the discussion to Bugzilla. Thank you for your research. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
