Re: [fossil-users] Continued issues with read-only repository
Okay cool, I'll tell the Air Force that's what they need to do. On Thu, Sep 21, 2017 at 7:13 AM, Roy Keene <fos...@rkeene.org> wrote: > Quit using Windows ? > > > On Wed, 20 Sep 2017, Andy Goth wrote: > > I'm fine in Linux working from a loopback-mounted ISO9660 disc image, >> but in Windows 8.1 doing the same nets me the following: >> >> SQLITE_NOTE: delayed 1375ms for lock/sharing conflict at line 43312 >> SQLITE_CANTOPEN: os_win.c:43319:(5) winOpen(E:\repo.fossil) - Access is >> denied. >> >> Followed by what appears to be normal operation. I get my web pages, >> and it seems good, except for three problems. >> >> One, page generation is a lot slower since I'm guessing it's having to >> wait a few seconds each request for some timeout. >> >> Two, the errors themselves appear at the top of every page. >> >> Three, the errors also appear in HTML format at the start of style.css, >> corrupting the first definition and messing up the page style. >> >> What can be done about this? >> >> -- >> Andy Goth | >> >> >> ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Andy Goth | ___ 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] Amended check-in time
On 09/21/17 19:51, Richard Hipp wrote: I don't have any idea [why] the tags are not working for you. Try this sequence: f new repo.fossil mkdir ckout cd ckout f open ../repo.fossil touch xxx f add xxx f commit -date-override 2018-01-01 -m 'add xxx' sleep 5 TIME=$(date +%FT%T) sleep 5 f rm -hard xxx f commit -allow-older -m 'remove xxx' f timeline f amend -date "$TIME" prev f timeline f rebuild f timeline The first timeline has a time warp, as expected: === 2018-01-01 === 00:00:00 [447719afb0] add xxx (user: andy tags: trunk) === 2017-09-22 === 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) +++ no more data (3) +++ The second timeline has the corrected time: === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) === 2017-09-21 === 20:47:15 [447719afb0] add xxx (user: andy tags: trunk) +++ no more data (4) +++ The third timeline, after the rebuild, has the original time warp again despite also showing the correction tag: === 2018-01-01 === 00:00:00 [447719afb0] add xxx (user: andy tags: trunk) === 2017-09-22 === 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) 01:47:20 [7196e2f3c2] *CURRENT* remove xxx (user: andy tags: trunk) 01:47:10 [602cd20f89] initial empty check-in (user: andy tags: trunk) +++ no more data (4) +++ This is fossil version 2.4 [493e3bade9] 2017-09-21 21:49:02 UTC -- Andy Goth | ___ 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 tag format
On 09/21/17 20:48, Andy Goth wrote: 01:47:20 [03d8e85285] Edit [447719afb096a7d3|447719afb0]: Timestamp 2017-09-21T20:47:15. (user: andy) A digression. What is the purpose of showing the edited artifact ID twice with two different lengths? This output was produced by the timeline command. -- Andy Goth | ___ 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] Continued issues with read-only repository
Nothing happens. By which I mean Fossil refuses to start, saying it sees no xyzzy here. So, twice as much happens. Therefore it is honoring my VFS change, and picking win32-none is not the solution to my problem. To reproduce, all that's needed is to set the repository file read-only in Windows, then run "fossil ui". On Sep 21, 2017 9:29 AM, "Richard Hipp" <d...@sqlite.org> wrote: On 9/21/17, Andy Goth <andrew.m.g...@gmail.com> wrote: > I added "set FOSSIL_VFS=win32-none" to my documentation viewer batch file. > This had no apparent effect. Is there another value I can give it that will > have a more dramatic effect to confirm it's being seen by Fossil? set FOSSIL_VFS=xyzzy Then run: fossil status You should see: no such VFS: "xyzzy" -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] enhanced-symlink branch
Please review the enhanced-symlink branch. I can't test it properly this weekend because I don't have Windows anywhere at home. On Monday I will give it another look, but perhaps before then someone else can try it out and share feedback. I'd like to get this merged into trunk and included in the next Fossil release, provided there are no objections. This branch adds a new "l" flag to the manifest setting. When specified, the "l" flag causes a new manifest.symlinks file to be created which lists all files which are symlinks. On Unix, that's the whole story, nothing more to say. On Windows, this new file can be edited to change which files are and are not considered to be symlinks. Thus, it becomes possible to create and unlink symlinks on Windows. I need this for a project that requires symlinks yet also needs to work in Windows. To make Fossil-style symlinks work in Windows, the few parts of my code that directly care about symlinks check a file I create in Linux that lists all the symlinks. Everything listed in that file is treated as Fossil-style symlinks, meaning that they are virtually replaced by whatever files or directories named within. To avoid having to keep this symlink file up-to-date, I would prefer that Fossil generate it for me the same way it generates its other manifest files. To enable me to actually change my symlinks while doing Windows development, I want this file to be read back in by "fossil changes" and "fossil commit", after having potentially been edited. None of this has any effect if the "l" flag is not set in the manifest setting. The effects of the "l" flag are also temporarily inhibited should the manifest.symlinks file be missing, though it will be regenerated after an update or a commit. If the manifest setting's value is "1" (one) not "l" (ell), the manifest.symlinks file is disabled. -- Andy Goth | ___ 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] enhanced-symlink branch
On 10/14/2017 5:16 PM, Andy Goth wrote: > Please review the enhanced-symlink branch. I can't test it properly > this weekend because I don't have Windows anywhere at home. Tested on Windows 7, works just the way my project needs it to work. The manifest.symlinks file is created when the "l" flag is present in the manifest setting. On Windows (not Unix), its contents determine what files are and are not considered to be symlinks. Editing the file influences the changes, status, and commit commands. I'd like to merge enhanced-symlink to trunk, but honestly I am afraid to just do so even though it passes all my tests because there's been zero mailing list discussion, aside from talking about Windows symlink functionality present on other branches which were themselves never merged to trunk. I still do not know my original change was moved off trunk. It didn't break compatibility, and it did provide a significant part of the needed functionality: listing symlinks in a way I can see them in Windows, short of parsing the manifest (another question I asked about that never got any replies on the mailing list). I asked for clarification for my code being moved off trunk but never got any. Now I see my most recent trunk check-in has also been moved off trunk, despite also not being a compatibility issue, with no explanation to either mailing list, my private email, or the check-in comment. I'm talking about http://fossil-scm.org/index.html/info/eb4dda482056b1db. Was there some policy change about committing to trunk that I missed out on? Before I spend any more time working on Fossil I need to know that I'm not doing something unwelcome. -- Andy Goth | 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] enhanced-symlink branch
On 10/16/17 21:13, Warren Young wrote: On Oct 16, 2017, at 7:28 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: I don't have the luxury of Cygwin because my end users won't have it. You can just distribute the DLL, then. The two programs that would need Cygwin are Fossil itself and my application. My application is written in Tcl and is bundled into a Starpack using a precompiled basekit. Said basekit is used both as the interpreter stub (placed inside the Starpack) and the standalone interpreter used to run the build script that actually creates the first Starpack. Only in the second role does it actually need to know anything about symlinks because they are used to define the layout of the Starpack virtual filesystem. Should I get a custom Cygwin-capable basekit, I'd be adding a dependency on Cygwin that complicates my install procedure without providing any runtime benefit. Or I could have two basekits, but that gives me an extra multi-megabyte blob providing no capability over and above what I have right now. Let me say that again. What I have works right now, and it's been working ever since the early days of my project. I see zero reason to incorporate Cygwin simply to avoid having to use the existing Fossil emulation of symlinks which already works fine for me. I'm curious, how far back does the Cygwin DLL work? I need to support all the way back to Windows 2000. Actually there's one Windows 98 system, but until they fix the network on it I can't support it anyway. Going the other direction, I think the newest system I have to support is Windows 7, although I do test on Windows 8.1. It's already like pulling teeth (don't get me started) to get them to allow fossil.exe to be on the install CD You can have an EXE but not a DLL linked to that EXE? I suppose dynamic linkage does increase the attack surface area, but it’s a pretty thin argument. The end user is simultaneously paranoid about security and ignorant about security. Please don't get me started. The whole reason I was given this project was to deal with this fact, and thus the slightest thing I do that they perceive as complicated (even if you and I know it's not) will cause me to fail in my task because they decline to adopt my solution and instead persist in manually doing the things that got them in trouble in the first place, and we are being held responsible for the consequences of their actions. It's not a happy situation. Let's not discuss it further. I'm not the one doing the reinventing. Except you are: there are at least 4 other existing implementations of symlinks for Windows, and you’ve just built a fifth. No I'm not. Fossil symlinks in Windows have always been ordinary files containing the names of their targets. That wasn't me. I'm merely exploiting this longstanding behavior because it's straightforward and does what I need. No, the current behavior for native Windows Fossil is to create ordinary files containing the name of their target (no trailing newline). I see why people keep trying to fix the problem, then. Right, it's fiddly and takes great care to use properly. Changing it is far outside the scope of my current effort. Others have already put forward alternatives on branches, but I'm not using them. I'm sticking with the bog-standard Fossil trunk here. I'm already taking heat for using Fossil in the first place, even though the alternative CM system I'm expected to use flat out doesn't work in the required development environment. For me to not only use Fossil but also some odd branch thereof would really push everyone over the edge. My work is focused on reflecting the list of symlinks back into the filesystem in the form of a manifest file. Granted, I could also have rewritten my code to parse the manifest file actually named "manifest" (not manifest.*) to find every line with the "l" permission, but I already wrote my application to read a newline-delimited list of filenames that does nothing more than list the symlinks, so I went with that simple format. Native Windows EXEs can call Cygwin EXEs, and vice versa. If the Tcl code doesn’t need to follow Fossil-created symlinks, Tcl needn’t be built under Cygwin. The Tcl code does need to follow the symlinks. The part of it that actually gets exposed to symlinks, I wrote to first look aside at the symlink list file so it knows which files to treat as such. Had I used Cygwin Fossil and Cygwin Tcl, that would all have been handled for me, at the cost of adding a runtime dependency on Cygwin and needing custom binaries of both that I can't be sure will work on all the required platforms, with a benefit experienced only during the Starpack build process that only developers will do. Though if you wanted, the Cygwin package repository should have a wide variety of Tcl stuff. Not the Starpack basekits though. Getting those to work right on Windows 2000 was enough of a chore. I don'
Re: [fossil-users] enhanced-symlink branch
On 10/16/2017 5:44 PM, Arseniy Terekhin wrote: > I want to share my thought about symlinking in fossil. > > dir "my_empy_dir" > dir "my_empy_dir2" > ln "existing_file_in_repo" "new_link" > ln_hard "existing_directory_in_repo" "new_hard_link" > attr_executable "bin/*.sh" > attr_hidden "*.cab" > > That setting can be applied whenever "empty-dirs" is currently applied. Everything you suggest can be placed in a makefile or other such script, no need to change Fossil to handle it. -- Andy Goth | 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] Built-in documents
Should /sitemap be added to the list of built-in documents in the new permutedindex.html? The built-in documents that were just added are already in the permuted index, which is fine, but when I asked myself if there are any other built-in documents, I thought of /sitemap. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Merge question
In response to Chris Rydalch saying that search-technote works for him, in combination with it passing all my tests, I'd like to merge it to trunk. What is the correct procedure for doing so? If I do: $ f up trunk $ f merge search-technote -baseline root:search-technote -integrate Then any future merge of annotation-enhancements will omit all changes made 2017-09-23 because the merge record will show that they were already merged due to being in the baseline of search-technote. To correct, said future merge would have to explicitly use the -baseline root:annotation-enhancements option. Instead I could cherrypick each of the five check-ins comprising the search-technote branch. This would avoid the aforementioned problem but, in addition to being a pain in the butt to do, would also not put a merge arrow in the graph. Of course, while said merge arrow is nice to see, its existence is responsible for said problem. A third approach would be to construct an alternative annotation-enhancements branch made by cherrypicking each of the search-technote check-ins, but this new branch would be rooted on trunk. Then merge that branch and be done. What's the best way to handle this situation? While on this subject, there are also a number of other changes on the annotation-enhancements branch that are unrelated to annotations. What do we do with them? At this point I'm inclined to just be patient and let annotation-enhancements be merged first. That would solve everything. Yet, my question remains. What is the best way to handle merging a branch-to-a-branch back to trunk without immediately incorporating unrelated branch changes while still allowing said changes to be incorporated when the branch is later merged? -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Tech note search
I implemented tech note search capability on the search-technote branch. Please have a look and let me know if it's good. Maybe the way I named things isn't so great, I dunno, so feel free to fix style or other conventions. If it's good, go ahead and integrate it to trunk. I opted to keep tech note searching largely separate from wiki searching because I feel tech notes serve a significantly different purpose. -- Andy Goth | ___ 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] Merge question
On 09/25/17 10:39, Richard Hipp wrote: On 9/25/17, Andy Goth <andrew.m.g...@gmail.com> wrote: As far as I can tell, in the general case I described in my previous email, assuming waiting was not an option, the best to do would have been to explicitly specify the -baseline option when merging the child branch and later when merging its parent branch. But this MUST be done in combination with additional testing to confirm that the child branch wasn't actually dependent on anything in its parent branch. And of course the final merge also must be tested to confirm it didn't leave anything out due to -baseline being forgotten or mistyped. Thoughts? I was thinking of changing --baseline so that it records the merge baseline using a Q card instead of a P card, as if the merge were a cherrypick. Not a bad idea at all. This avoids the second part of the problem quite nicely. If I recall correctly, the Q card supports listing a range of merged check-ins even though this feature is never actually used in practice. As for the user desire that a merge arrow be shown, I feel this would best be addressed by showing cherrypick and backout merges. I wrote up this wishlist item eons ago but never got around to working on it. Does anyone have any new ideas about this? How should such alternative merge arrows be rendered? Colors? Can dashed lines be shown? Can the arrowhead be a symbol such as a tiny circle or an X? -- Andy Goth | ___ 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] Merge question
On 09/25/17 10:18, Richard Hipp wrote: On 9/25/17, Andy Goth <andrew.m.g...@gmail.com> wrote: In response to Chris Rydalch saying that search-technote works for him, in combination with it passing all my tests, I'd like to merge it to trunk. What is the correct procedure for doing so? At this point I'm inclined to just be patient and let annotation-enhancements be merged first. That would solve everything. Merged now. Thank you for your testing and your corrections. I don't have access to any Ubuntu systems, so I didn't spot the original problem you came across. (No clue why Ubuntu has -Werror on by default, or whatever was going on. Might want to explicitly turn on more warnings like -Wunused or -Wall or even -Wextra to help spot these types of issues.) As far as I can tell, in the general case I described in my previous email, assuming waiting was not an option, the best to do would have been to explicitly specify the -baseline option when merging the child branch and later when merging its parent branch. But this MUST be done in combination with additional testing to confirm that the child branch wasn't actually dependent on anything in its parent branch. And of course the final merge also must be tested to confirm it didn't leave anything out due to -baseline being forgotten or mistyped. Thoughts? -- Andy Goth | ___ 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] Tech note search
On 09/25/17 09:35, Chris Rydalch wrote: Thanks so much Andy, this is great! So far so good on my end... Merged to trunk, along with all the other recent developments. Please update and test some more, if you don't mind. -- Andy Goth | ___ 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] Amended check-in time
On 09/21/17 20:48, Andy Goth wrote: On 09/21/17 19:51, Richard Hipp wrote: I don't have any idea [why] the tags are not working for you. Try this sequence: f new repo.fossil mkdir ckout cd ckout f open ../repo.fossil touch xxx f add xxx f commit -date-override 2018-01-01 -m 'add xxx' sleep 5 TIME=$(date +%FT%T) sleep 5 f rm -hard xxx f commit -allow-older -m 'remove xxx' f timeline f amend -date "$TIME" prev f timeline f rebuild f timeline Has anyone tried running these commands yet? I want to see if anyone else can replicate my problem. Correction: Replace "date +%FT%T" with "date -u +%FT%T" to avoid timezone problems. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] manifest setting "l" flag
http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8 I added support for a new "l" flag to the "manifest" setting. With this flag present, a new file "manifest.symlinks" is automatically created and maintained. This file lists all symlinks (not their targets). I need this feature for a project that makes extensive use of symlinks and has to work on Windows even though the OS doesn't really have symlinks (at least not symlinks to files). On this project, I currently have a symlink list file which I maintain by running a script on Linux and checking in the result. When I run on Windows, everything in the project that actually needs to use symlinks looks at the symlinks file to see if it should read the file to get its target before proceeding. This works pretty well for me but is kind of awkward. I'd rather have the symlinks file be kept up to date, no fooling, without being a separately checked-in file. However, it's not 100% what I need. When working on Windows, I'd like to also be able to edit manifest.symlinks to change which files are and are not considered to be symlinks. I believe the current Fossil logic for handling symlinks on Windows is to create them as ordinary files containing their targets (no trailing newline), then leave them as symlinks in the manifest until they are changed. I'm thinking that when the "l" flag is set, the logic would instead be to reread the manifest.symlinks file when doing a commit and use it to decide what to mark as symlinks in the manifest. Said logic would only apply in Windows. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Manifest command and ambiguous names
I'd be interested in having a command to get the manifest of a check-in. The artifact command comes up short when the check-in happens to have a delta manifest. I wrote a Tcl script to combine a delta manifest with its baseline, but I think it would be preferable to expose this capability already available inside Fossil. The trouble is the obvious choice of name for this command would be "fossil manifest", yet "manifest" is already the name of a setting. [f74f7014] combined the settings with the commands and web pages in the aCommand table. Should we add a manifest command, there would be two entries with the same name. I recently modified dispatch_name_search() to tolerate prefixes being shared between entries of different types. I can modify it further to tolerate different-type entries having the same names outright. However, there's still trouble when eType is CMDFLAG_ANY, i.e. when dispatch_name_search() is called by help_page() or help_cmd(). What to do? I could give up and continue to use my Tcl script, I could contribute my Tcl script for others to use, we could call the command that prints a manifest something other than "manifest", or we could add an alternative to dispatch_name_search() that can return more than one result. In that last case, "fossil help manifest" would print help for both the command and the setting. Thoughts? -- Andy Goth | ___ 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] web UI for a working checkout?
On 09/30/17 13:34, Andy Bradford wrote: Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600: Who is hosting that and what is the longevity compared to github and others? Longevity on the Internet seems to be an often nebulous thing. How long was Google Code (code.google.com) around? How long did Source Forge last before people started ditching it? The nice thing about chiselapp.com is that it's really just Fossil. If chiselapp.com dies, you still have your source (assuming you clone and sync with chiselapp.com frequently) and it wouldn't take much to find a new host to put it on. One of the goals of Fossil was to transcend the problem of depending on the survival and continued interest of others by producing an enduring file format that can outlast any particular developer, software package, hosting service, or even database system. At heart, your Fossil repository is what you see when you do a deconstruct: a collection of artifacts, named by their checksums, tied together by manifests and other structural artifacts. The Fossil code base, the SQLite database, the Fossil web site, the Fossil developers, and the Fossil community exist to support this format, but should all these disappear, both your development history and your development future are safe. -- Andy Goth | ___ 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 and Emacs
On 10/01/17 07:07, Paul Onions wrote: https://chiselapp.com/user/venks/repository/emacs-fossil > So now I'm wondering, is this project actively maintained anymore? Try contacting avanv...@pragmatic-c.com. That's the only email address I could find amongst any of the repositories owned by the same user as emacs-fossil. -- Andy Goth | ___ 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] manifest setting "l" flag
On 09/29/17 04:20, Richard Hipp wrote: On 9/28/17, Andy Goth <andrew.m.g...@gmail.com> wrote: http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8 Moved onto a branch: enhanced-symlink I thought about branching when I checked in, but I decided to stick with trunk because this can't affect any existing repositories. No one is using "l" for a different purpose. Why the branch now? Because there is more work to do before it meets my own needs? That would make sense. Any thoughts or discussion, anyone? -- Andy Goth | ___ 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] manifest setting "l" flag
On 09/28/17 21:34, Scott Robison wrote: There is a winsymlink branch I created some time ago. Hasn't been kept up to date (I didn't need it, just thought it might be useful for feature parity) but I could take a look at it if you were interested. Or you could. I had a peek. I know Windows NT derivatives allow symlinks to directories but was not aware any version of Windows allowed symlinks to files. What is the status of that? Having symlinks in Windows may seem cool at first, but it would actually be counterproductive without a good way to edit them. If Fossil is the only program on hand that can create, change, or unlink them, it might as well not even try. With the design I'm working toward, symlinks could be created, changed, or unlinked by editing the link file to contain its target and/or by editing manifest.symlinks to contain or not contain the link file name. Plus, the project I'm doing has to work all the way back to Windows 2000 and (maybe, possibly, unconfirmed) Windows 98. While it's not the end of the world if there are some platforms which can't be used as a build or development platform, right now I have it so that any supported system is fully capable of developing for all supported systems: Linux for Windows, Windows for Linux, etc. Therefore I do not want to rely on features that aren't bog standard throughout every version of Windows, 95 onward because long filenames. -- Andy Goth | ___ 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] web UI for a working checkout?
On 9/29/2017 3:15 PM, Steve Schow wrote: > Is anyone aware of any Web based ui for working with a working > checkout? I’m looking for the ability to have a web app that can > basically execute things like commit, branch, update and other > checkout related fossil commands, operating on a checkout directory > tree located on the webserver of course… http://chiselapp.com/ comes closest in that it provides a web interface for working on repositories as a whole. It does not provide what you ask, nor do I know of any other web platforms that do. The trouble is that in order for a checkout user interface to be meaningful, it needs to be bundled with tools to actually edit the checkout files. Otherwise there's little point. From the perspective of most programmers, web browsers can't compete with dedicated text editors, so what you describe will likely not be successful in targeting programmers. One thing that could happen is for "fossil ui" itself to get more checkout functionality, since it does indeed get used in combination with checkout editing. Since it's used in conjunction with the command line, it does not make any effort to replace the command line. But that doesn't mean it can't be an alternative interface, just like how it provides an alternative to diffing historical files from the command line. Personally I'm not interested in "fossil ui" performing the checkout manipulations you describe, but nevertheless I would like it to be a bit more aware of checkouts, e.g. to diff the current checkout with its baseline check-in or other versions, to show the list of changes, or to show and manage stashes. -- Andy Goth | 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] web UI for a working checkout?
On 9/29/2017 4:43 PM, Steve Schow wrote: > On Sep 29, 2017, at 2:46 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: >> http://chiselapp.com/ > > Hey thats pretty cool, I was not even aware of that site! I am going > to check that out, I guess that’s a decent way to keep a repo public, > then I can clone it here locally for working on stuff. Spread the word! > But that webui just looks pretty much like the same one built into the > fossil binary, yes? When you're viewing any particular repository, yes. Chisel provides everything else surrounding the repositories. > Who is hosting that and what is the longevity compared to github and > others? Roy Keene can answer these questions. > Primary interest right now is in using a headless machine that will be > hosting a repo. And often users will not have command line access > either. In the simplest case, I could set it up, with web ui access > to the repo itself, but then always require them to clone the repo on > another machine and do all their edits there and push their changes > back to remote master repo. That is the basic arrangement Fossil was designed for. > But it turns out there is also a use case for them being able to add > files and commits to the repo directly on the headless linux box > without having to clone the repo to another client machine. I supposed one could call this a hosted development environment. Though let me add to what I said earlier (needing an editor, etc.) to point out that development is meaningless without testing. Unless the product being developed is documentation and testing is accomplished by reading the document as formatted by a browser, your users are going to want to be able to compile and run whatever they are making. Will your web platform provide that too? It's not totally out of the question, and I've seen submit-your-code-and-we'll-run-it stuff before. I'm just saying that there's a lot to consider before you reach the point that what you've put together is actually useful. > I hear what you’re saying about no way to edit without command line, > but actually it would be perfectly fine to have the check out dir tree > accessible via SMB share.. Then they can edit the files over SMB. > But without command line access there is no way for them to commit the > changes into fossil. That’s where a Web UI for some of those commands > would be useful. I would strongly advise against SMB over the public Internet. VPN may work, also you can use SMB within the firewalls of your organization. Basically you're sidestepping the requirement to provide a web interface to file management and editing, which is fine. Just, like I said above, remember that not only do you have to have file management/editing and access to Fossil commands, but you also need to be able to build and test whatever is being developed. The requirements snowball the more you think about them. > But this could also be useful even when running fossil alone on a > local desktop machine. Kind of like when you run “fossil ui” and up > pops a web interface to the fossil repo on the local machine. Still > edit the files with vi, etc, but the fossil UI basically accesses the > DB right now…it doesn’t touch any checked out dir trees or provide any > way to use the UI to do stuff on them…. Okay, now we're agreeing on something. The web interface has limited cognizance of the checkout in which it is being run. It can highlight whichever check-in is currently checked out, and (quite important to me right now) /doc can serve the "ckout" version for instant feedback on my markup, etc. More checkout-sensitive capability would be nice. The examples I gave before are diffing the checkout and managing the stash. Yet, diffing is a strictly read-only operation, and managing the stash is likely either read-only or doesn't affect the checkout files. Providing web-driven manipulation of the checkout is a big step, one I'm not opposed to, but one I don't think we've ever considered. > which is what I wish it could..then it could be a fairly platform > independent checkout GUI….including over to headless linux boxes that > might have a check out there also. Headless Linux boxes have never been a problem for most folks because of SSH, X11, VNC, etc. Platform-independent GUIs however, that is an attractive concept. It's one we already enjoy in many respects, so why not more, huh? > Ultimately I guess I will have to roll out my own, as I don’t think > anything exists and I doubt there is much interest. Is there a reason why your developers can't clone their own repositories onto their own machines and do their work there in the environment that's most comfortable for them? If you need a shared server because everyone runs Windows at their desk yet development must be done in Linux for various reasons, please consider giv
Re: [fossil-users] Minor typos in fossil documentation
On 08/24/17 04:48, rosscann...@fastmail.com wrote: The fossil documentation is so good, it's a shame to allow even the tiniest imperfection! Thanks, fixed. Please review: http://fossil-scm.org/index.html/info/f98852a0df35ef2a -- Andy Goth | ___ 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] toc.tcl
It's online now. Also, here's the code:
#!/usr/bin/env tclsh
package require Tcl 8.6
# Link back to table of contents.
set top {[top]}
# Process each named file.
foreach file $argv {
# Read Markdown file.
set chan [open $file]
set data [chan read $chan]
chan close $chan
# Check if the Markdown file contains a TOC.
if {[string first $data] >= 0} {
# If so, build the TOC to contain all first- and second-level
headings.
# Consider only headings using "#" and "##" marks, not underlines.
set start 0
set toc
append toc "\n"
append toc " Table of Contents\n" [string repeat = 50]
while {[regexp -indices -line -start $start {^##?[^#].*} $data
match]} {
# Get line from input.
set line [string range $data {*}$match]
# Get heading level.
regexp {^(#*)(.*)} $line _ heading line
# Strip the anchor tag if present.
regsub {^ } $line {} line
# Strip the link to the TOC if present.
regsub { "
# Build table of contents.
append toc \n
if {$heading eq "##"} {
append toc " "
}
append toc "* \[$title\](#$name)"
# Replace the section header line.
set line "$heading $anchor $title $top"
set data [string replace $data {*}$match $line]
# Update the start index.
set start [expr {[lindex $match 0] + [string length $line]}]
}
append toc \n
# Write Markdown file with the table of contents inserted.
set chan [open $file w]
chan puts -nonewline $chan [regsub -line
{^$(?:\n.+$)*\n$}\
$data [string map {& \& \\ } $toc]]
chan close $chan
}
}
# vim: set sts=4 sw=4 tw=80 et ft=tcl:
On Aug 21, 2017 09:47, "jungle Boogie" <jungleboog...@gmail.com> wrote:
> On 20 August 2017 at 10:24, Andy Goth <andrew.m.g...@gmail.com> wrote:
> > On 08/18/17 07:38, Dewey Hylton wrote:
> >>
> >> I predict this to be the best email I receive today.
> >>
> >> My first thought was "This is like paid support!"
> >> My second thought was "Wait ... paid support has *never* been this good
> >> ..."
> >>
> >> Thanks for your work!
> >
> >
> > Since you seem to be really interested, have one more improvement. Now
> > there's no need for an marker. The table of contents extends
> > from to the first blank line. Aside from looking cleaner
> > overall, this works around a Markdown rendering oddity which required me
> to
> > put a blank line between the last line of the TOC list and the
> > line.
> >
> >
> > https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl
> >
>
>
> Any chance of using something like https://www.pastiebin.com to show the
> code?
> chiselapp.com is offline, and it looks like that's been the case of a
> few days now.
> ___
> 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] toc.tcl
On 08/27/17 21:14, dewey.hyl...@gmail.com wrote: my static site generator leverages blackfriday for markdown parsing, and pygment-colored code blocks are framed with "```" ... these blocks do not get ignored by your script, and the commented lines inside the code blocks get meddled with. "```" is not special to Fossil, so it's not recognized by my script. But that's easily remedied. Please try: https://chiselapp.com/user/andy/repository/brush/file/doc/toc.tcl To keep this email relevant to Fossil, let me ask if there is any interest in adding "```" which appears to be intended to mark a code block without having to indent each line. I vote no because what we have works for me, but others may disagree. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New release?
At work I'm having some difficulty due to the most recent released version of Fossil not including my correction for /doc on read-only repository files. Would it be possible to make another release to include this and other recent changes? The branch titled branch-2.3 seems to collect high-priority bug fixes slated for inclusion in future version 2.3.1. However, it doesn't have [95edba65] nor [da23bec7] which are most important to me, nor does it have my most recent Markdown documentation update which also matters for my project because it is referenced by deliverable documentation. -- Andy Goth | ___ 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] New release?
On 08/30/17 06:05, Richard Hipp wrote: On 8/29/17, Andy Goth <andrew.m.g...@gmail.com> wrote: At work I'm having some difficulty due to the most recent released version of Fossil not including my correction for /doc on read-only repository files. Would it be possible to make another release to include this and other recent changes? Can you not just download and compile the latest trunk? I tried that once, had trouble with my self-compiled Windows binary having the right icon and other such frou-frou. But yeah, that's probably the best solution regardless because I can do it immediately without having to wait for someone else's release schedule. Is there a compilation guide that says how exactly the official Windows binaries are produced? I'd like to get that part right if I can. On Linux I build Fossil myself all the time. It's just Windows that's a headache for me. -- Andy Goth | ___ 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] toc.tcl
On 08/29/17 21:18, Offray Vladimir Luna Cárdenas wrote:
On 29/08/17 20:11, Andy Goth wrote:
To keep this email relevant to Fossil, let me ask if there is any
interest in adding "```" which appears to be intended to mark a code
block without having to indent each line. I vote no because what we
have works for me, but others may disagree.
I would vote yes. It's used in Pandoc's markdown and others and is
becoming a standard practices for documentation made with this popular
Markdown families.
dewey.hylton says "```" imbues syntax highlighting whereas indented
lines are left plain. Fossil doesn't do any kind of syntax highlighting
at this point. Is there any interest in having this feature? I feel
syntax highlighting is both expected and bloat. We would have to decide
which we prefer: being simple or having me-too features.
I'm curious how the Markdown formatter would know what language rules to
use for syntax highlighting, so surely there's more to the syntax than
bracketing ("fencing") the code with lines consisting entirely of "```".
I searched online and found the answer to be: put the name of the syntax
highlight mode (i.e. the language) right after the first "```" on the
same line, for instance "```ruby".
I have updated my toc.tcl to allow for extra text to follow "```". The
change is committed to chiselapp. dewey.hylton, please review.
--
Andy Goth |
___
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] enhanced-symlink branch
On 10/18/17 08:42, Florian Balmer wrote: Handling Windows Shell Links (*.lnk) can be tricky: Off-topic, but does anyone know a good way to create *.lnk files from Tcl? The only way I've found is to use DDE to create start menu shortcuts, then move those shortcut files to wherever I need them, because they are in fact *.lnk files. This has some serious drawbacks, but again, it's the only way I've found to make *.lnk files at all. Because off-topic, please consider replying to me privately. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fwd: Re: Fossil README symlink
I received this email from Matias Fonzo in reply to a message I sent him earlier today. With his permission, I am forwarding it to the list. The bottom line is that the requiring JavaScript access has proven to be fatal for his project's usage of Fossil. Forwarded Message Subject: Re: Fossil README symlink Date: Tue, 17 Oct 2017 21:49:35 -0300 From: Matias Fonzo <s...@dragora.org> Organization: Dragora GNU/Linux-Libre To: Andy Goth <andrew.m.g...@gmail.com> Hello Andy, I'm happy that you (a developer of Fossil) wrote me. Also, glad to see that you solved the symlink issue, but i am afraid that is too late for us to continue using Fossil. We migrated to Git[1] (again): [1] http://git.savannah.nongnu.org/cgit/dragora.git/ This was our previous home prior to switch to Fossil. Fossil is a great software and I consider it better than Git. The problem is the Javascript code to avoid the spam, and some people reported that they can not enter to the Dragora's website, which is a problem for me[2]. [2] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25230.html On Tue, 17 Oct 2017 10:33:13 -0500 Andy Goth <andrew.m.g...@gmail.com> wrote: > I see your README file at the top level is a symlink. This causes > "www/overview.md" (the filename, not the contents) to be shown when > browsing the top level directory in the /dir or /tree Fossil web > pages. > > You might want to have a look at the doc-symlink branch of Fossil. > In it I add support for README files being symlinks. > > http://fossil-scm.org/index.html/timeline?r=doc-symlink > > Please let me know your thoughts on this feature, also if you are > okay with me sharing them with the Fossil mailing list. > 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] Content-Security-Policy Was: Fossil README symlink
On 10/18/17 09:46, Warren Young wrote: On Oct 18, 2017, at 8:27 AM, Warren Young <war...@etr-usa.com> wrote: On Oct 18, 2017, at 7:04 AM, Richard Hipp <d...@sqlite.org> wrote: I'll have to add a "/fossil.js” resource While you’re about it, I’d suggest shipping /fossil-$hash.js instead and setting a multi-year Expires header for the file so that it only has to be pulled once and cached “forever”. $hash is the current Fossil checkin prefix, the same one reported by “fossil ver”. Thus, whenever Fossil changes, the file name changes, so the browser will pull the fossil.js file again. +1 to this idea. Ditto style.css, though the ability to change the CSS via Fossil UI complicates this. Currently, that gets pulled on every page load, even though it almost never changes. +0.98 to this idea. I'll contribute the remaining two cents by suggesting style-$hash2.css where $hash2 is a hash (or prefix thereof) of the contents of style.css, possibly combined with the Fossil checkin prefix. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fwd: Re: Fossil README symlink
More from Dragora about JavaScript. The part that's most interesting to me is they're not using Github. -- Forwarded message -- From: "Matias Fonzo" <s...@dragora.org> Date: Oct 18, 2017 13:26 Subject: Re: Fossil README symlink To: "Andy Goth" <andrew.m.g...@gmail.com> Cc: Hi Andy, On Wed, 18 Oct 2017 09:48:44 -0500 Andy Goth <andrew.m.g...@gmail.com> wrote: > > Here's the origin of the rest of the thread, if you wish to see: > > [..] Thanks. > > I think this is a good thing. Thank you for helping to get this ball > rolling. Hopefully it will bear fruit, even if it's not precisely > what you were asking for. > No problem. Two things, the report of the people is not about the login page only. They can't see some of the pages, cannot remember exactly those, but i think it was about the content, and the Timeline. I've followed the suggestions to try to avoid Javascript, but without luck. Probably is my bad interpretation, but we are not in Github (just in case, to make it clear). Currently, we have a mirror[1] in notabug.org (which is an alternative to Github). [1] http://notabug.org/dragora Best regards, Matías ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Amendments don't always survive rebuilds
Some amendments don't consistently survive rebuilds and syncs. I've noticed this with date changes and reparenting. Possibly it affects other types of amendments as well, but those are the two I've spotted. This has been plaguing me for years, but finally I have a repeatable test case. Repository before rebuild: https://drive.google.com/open?id=1-Ahs91NVigBX7uMk88wIBjClQj1yxGnm Repository after rebuild: https://drive.google.com/open?id=1CFzc9JyNQ5piSIO4YUqjSpqmmjPxmCsg I constructed a repository full of time warps, much like in my previous email about the stray riser. Then I used a bunch of amendments to straighten everything out. But once I rebuilt, the dates got jumbled again, and not in the same configuration as when I started. Some amendments survived, others didn't. Here are the commands I used to create the repository: f new test.fossil -admin-user username -date-override 2018-05-31 mkdir test cd test f open ../test.fossil f user default username id=1; for day in 15 13 16 12 17 11 18 10 19 09 20 08 21 07 22 06 23 05 24 04 25 03 26 02 27 01; do f commit -f -m "$id" -tag "$id" -date-override "2018-06-$day"; ((++id)); done for id in $(seq 1 26); do f amend -date "$(printf 2018-06-%02d "$id")" "$id"; done And then, to mess it up again: f rebuild I could also have sync'ed to another repository, but here I'm just showing the simplest way I know to trigger the problem. I wonder if the order in which artifacts are visited is impacting the outcome. -- Andy Goth | ___ 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 SlackBuild script
I just submitted an update to the Fossil SlackBuild script. Sorry, I haven't done this since version 2.3, and now we're on 2.6. I took the opportunity to update the README file with a few new bullet points and features. Here it is, pasted inline: Fossil is a distributed version control and ticket tracking system created by D. Richard Hipp, the primary author of SQLite. Features: - tamper-proof artifact record - simple command-line interface - customizable web interface with JSON, RSS, and built-in wiki - online project documentation with full-text search capability - online activity and ticket reports - user accounts with access controls - coherent versioning across all files - straightforward branching and merging - bisect searches to pinpoint behavior changes - SHA3-256 and hardened SHA1 checksums - FUSE filesystem makes all historical and branch revisions available - synchronization via http, https, ssh, and local/network filesystems - automated replication and backup - git import/export and Subversion/CVS import - nested checkouts to share common subtrees across related projects - checkout directory not cluttered with administrative files - support for Docker - unversioned file area for builds, statistics, other ephemeral content - optional PGP signing of commits - private branch which are excluded from syncs until published - bundles group a change set (e.g. a private branch) into a single file - users can make their own repositories, no need for special privileges - works in Windows as well as Linux and other Unix-like systems Fossil can host the entire project development website, including the download area, but it also can be used for individual projects with no need for a shared server. In addition to typical software development operations, one interesting application is coordination and auditing of /etc and other configuration files across a network of computers. Content is stored in an SQLite database for atomicity, durability, and effortless administration. See Fossil in action online: - https://fossil-scm.org/ - Fossil hosts its own development - https://sqlite.org/src/ - Fossil originally created to manage SQLite - https://core.tcl.tk/tcl/timeline?y=ci - Tcl/Tk migrated from CVS - https://chiselapp.com/ - Free public hosting for Fossil projects Key technical points: - unified revision history tree spans the entire repository - repository is a collection of artifacts identified by their checksums - artifacts are broadly grouped into content and structural artifacts - each check-in is tracked as a structural artifact known as a manifest - manifests primarily list the full names and checksums of each file - manifests can be amended by subsequent control artifacts - in most cases, symbolic names refer to the latest matching check-in - branches are implemented using propagating symbolic tags -- Andy Goth | ___ 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] Compressed >>> uncompressed size
On 06/07/18 14:00, Andy Goth wrote: On 06/07/18 08:51, Richard Hipp wrote: On 6/7/18, Andy Goth wrote: In a couple of my repositories (sorry, I can't share them), /artifact_stats shows artifact compressed sizes far larger than uncompressed sizes. Can you send the HTML generated by /artifact_stats? Sure, though with some redactions. May I attach it to my email? I'm sorry, I can't wait any longer. I gotta run to somewhere else and won't have access to email. I've asked three times about attachments and haven't gotten an answer, so I'm just going to go ahead and attach the file. If it works, great. If not, well, hopefully it won't break digests and archives and all that. -- Andy Goth | Title: REDACTED: Artifact Statistics REDACTEDArtifact Statistics REDACTED â Logout Home Timeline Download Code Docs Branches Tags Site Map Admin Help Artifact List Repository Stats Overall Artifact Size Statistics: Number of artifacts:5,539 Number of deltas:3,336 (60%) Number of full-text:2,203 (39%) Uncompressed artifact sizes:largest: 5,913,941, average: 33,982, median: 7,168 Compressed artifact sizes:largest: 3,836,467, average: 11,017, median: 228 Delta artifact sizes:largest: 2,435,585, average: 5,384, median: 154 Full-text artifact sizes: largest: 3,836,467, average: 19,547, median: 1,904 Artifact size distribution facts: The largest 0.18% of artifacts (the largest 10 artifacts) use 50% of the total artifact space. The largest 1% of artifacts (the largest 56 artifacts) use 83% of the total artifact space. The largest 10% of artifacts (the largest 554 artifacts) use 94% of the total artifact space. The largest 25% of artifacts (the largest 1,108 artifacts) use 97% of the total artifact space. The largest 50% of artifacts (the largest 2,770 artifacts) use 99% of the total artifact space. Artifact Sizes By Type: Artifact Type Count Full-Text Delta Compressed Size Uncompressed Size tag 86 86 0 50,281,182,134,272 13,628 cluster 55 55 0 630,561,328,594,944 259,433 manifest 1,261 185 1,076 24,307,088,238,837,760 61,165,438 file 4,137 1,877 2,260 237,119,934,616,829,952 126,791,819 ALL 5,539 2,203 3,336 262,107,865,366,396,928 188,230,318 This page was generated in about 0.116s by Fossil 2.6 [7ac88481a6] 2018-06-07 00:45:54 ___ 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] Compressed >>> uncompressed size
32-bit Linux, no custom modifications, Fossil version e80667191a, self-compiled, ok. 5913941|3836467 5800401|3765158 3670410|3369067 3957878|3035526 3952468|3029402 3951235|2969330 3923360|2946572 4234202|2663321 5772779|2435585 3459064|2370320 I count 243 rows where length(content)>size, and max(length(content)-size) is 20. On Thu, Jun 7, 2018, 14:40 Richard Hipp wrote: > On 6/7/18, Andy Goth wrote: > > > > I'm just going to go ahead and attach > > the file. > > Very peculiar output. What platform is this running on? Have you > made any modifications? Did you compile Fossil yourself? > > Try this: > > fossil sql "pragma integrity_check" > > If that returns "ok", then try this: > > fossil sql "select size, length(content) from blob order by 2 desc > limit 10" > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SlackBuilds.org GitHub repository and DMCA Takedown notice
A few days ago, SBo and over 200 other repositories in GitHub were hit with a DMCA Takedown notice due to having a couple header files from Steinberg Media Technologies. There's a lot to say about that, particularly if you're into computer music synthesis, but I don't think this mailing list is the appropriate forum to discuss Steinberg's action. Instead I want to discuss the technical means by which any of the affected projects would comply with the takedown, had they been using Fossil. Quote from the SBo blog post: "The admins have discussed this matter last night and we came to a solution of fixing this issue permanently by removing the related commit and all the history for this script in master and 14.2 branch. This is not a trivial action as the commits involved were 11867 since 2017-02-04. Ponce did the initial testing and David did the final touch, including pushing an unexpected public update including with the mass re-base on master and 14.2 branch (Thanks David)." The post goes on to include a sequence of commands to be followed by everyone downstream to surgically fix their local clone of the SBo repository. "[A] simpler way is to re-clone our repository using git clone." Am I correct in my understanding that all a Fossil repository need do is issue shun artifacts for each file in the takedown notice? If the files had multiple versions (they didn't in this case), shun each version of them too, right? This would result in the file vanishing from every repository clone upon the next sync, though its name and checksum would remain in manifests. Any code #include'ing the header files (in this case) would fail to compile, on account of the missing file, so it would no longer be possible to recompile historical check-ins, not without creating a compatible replacement for the shunned files. Here's the original blog post I found: https://slackblogs.blogspot.com/2018/06/sbo-dmca-takedown.html For your curiosity, here's Google's cache of one of the affected files, but I'm sure Google will take it down too, so look quick. Right now, the important part is the comment "© 2006, Steinberg Media Technologies, All Rights Reserved". https://webcache.googleusercontent.com/search?q=cache:X4F7NEfgUlkJ:https://github.com/aardvarkk/soundfind/blob/master/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h+=1=en=clnk=us=firefox-b-1 -- Andy Goth | ___ 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] style.css served with on settings conflict
On 06/07/18 19:55, Warren Young wrote: The error prepended to web pages served by Fossil on settings conflicts is being prepended to the style.css file, causing the CSS to be considered invalid by Chrome, at least. This should be done on HTML output only. I had this same problem back when we were having trouble with read-only repositories on Windows. Richard fixed it by reworking how SQLite deals with Windows virus scanners lying about file access, but we never actually changed the error logger. In the case of CSS, errors can still be reported, but they have to be made to look like comments. Text prepended to HTML tends to be tolerated as-is though, so only CSS needs a fix. Trouble is, how does the error logger know that its output will wind up inside CSS? -- Andy Goth | ___ 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] Incorrect arrow colors when using -bgcolor
On 06/06/18 19:46, Richard Hipp wrote: On 6/6/18, Andy Goth wrote: When a custom bgcolor is set for a check-in, the arrow color coming out of the check-in is incorrect. In my test case, the outbound arrows are white, which doesn't look so great against the default white background. Fixed on trunk Thank you for the quick turnaround! Fix confirmed good. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Stray up arrow in timeline
While investigating a difficult-to-reproduce problem with rebuilds (to be discussed in a separate email if I ever come up with a procedure), I managed to get another problem. My timeline now has a stray up arrow coming off the check-in that comes "after" the one for which I amended the time. In the full timeline, the arrow goes upward toward infinity. It does not show in the context/family timelines, only the full timeline. I say "after" in quotes because the one I amended used to have a date before its successor but now has a date slightly after its successor, that successor being the one with the stray up arrow. In the end, I have two check-ins in a row that have dates preceding their predecessors. (My dates are squirrelly on purpose; that's not the point.) I'd like to post the repository but am asking permission first in a separate email because it's a binary file. Tiny though it may be, attachments often don't go well with mailing lists, particularly not binary attachments. Naturally, I can send it to anyone who requests it, if anyone's curious and can't wait for me to get the official nod. -- Andy Goth | ___ 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] Stray up arrow in timeline
On 06/06/18 20:58, Andy Goth wrote: While investigating a difficult-to-reproduce problem with rebuilds (to be discussed in a separate email if I ever come up with a procedure), I managed to get another problem. My timeline now has a stray up arrow coming off the check-in that comes "after" the one for which I amended the time. In the full timeline, the arrow goes upward toward infinity. It does not show in the context/family timelines, only the full timeline. Here is the procedure I followed, with timestamps: # Date: 2018-06-06 # Time zone: -0500 20:40:53 f new uparrow.fossil 20:40:54 mkdir test 20:40:55 cd test 20:40:59 f open ../uparrow.fossil 20:41:23 f commit -m 1 -tag 1 -allow-empty 20:41:26 f info 1 20:41:49 f commit -m 2 -tag 2 -allow-empty -allow-older -date-override 2018-01-01 20:41:56 f commit -m 3 -tag 3 -allow-empty 20:42:04 f commit -m 4 -tag 4 -allow-empty -allow-older -date-override 2017-01-01 20:42:08 f commit -m 5 -tag 5 -allow-empty 20:42:13 f commit -m 6 -tag 6 -allow-empty -allow-older -date-override 2016-01-01 20:42:17 f commit -m 7 -tag 7 -allow-empty 20:42:23 f commit -m 8 -tag 8 -allow-empty -allow-older -date-override 2015-01-01 20:42:27 f commit -m 9 -tag 9 -allow-empty 20:42:34 f commit -m 10 -tag 10 -allow-empty -allow-older -date-override 2014-01-01 20:42:38 f commit -m 11 -tag 11 -allow-empty 20:43:27 f rebuild 20:44:16 f amend -date 2018-06-07T01:42 2 I doubt that rebuild has anything to do with it, but nevertheless it's there in my shell history. I'd like to post the repository https://drive.google.com/open?id=1hCAqmgYxO30gF-mYeQsgP2HLIl6gC11A -- Andy Goth | ___ 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] Show time...
On 06/06/18 20:26, Eduard wrote: I might enable public registration 'soon'. Now all I need is a catchy name, like `chiselapp` :p There are plenty of fossil terms to choose from, for example archaeo. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Attachment policy
What is the file attachment policy for this mailing list? I couldn't find it documented anywhere. It doesn't help that when I search the list for "attachment" I find so much about ticket attachments. May I attach plain text files? Binary files? What are the size limits? I have an 8.7 kilobyte binary file I'd like to attach (xz -9 compressed test repository), as well as an image file because I'm at a loss to describe what I'm seeing in the timeline. -- Andy Goth | ___ 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] Attachment policy
On 06/06/18 21:53, jungle Boogie wrote: Seeing that you have a Gmail account, you could upload to Google drive and make public. Then provide the link via email to that file. I'll do that for now, pending direction to attach to email or do anything else. Ideally the file would not be in separate storage from the email, but the way email attachments work sucks in general, so if we can't achieve this ideal, I understand. -- Andy Goth | ___ 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 arrow colors when using -bgcolor
When a custom bgcolor is set for a check-in, the arrow color coming out of the check-in is incorrect. In my test case, the outbound arrows are white, which doesn't look so great against the default white background. f new test.fossil mkdir test cd test f open ../test.fossil touch file f add file f commit -m 1 -bgcolor '#00aa00' echo moo > file f commit -m 2 -bgcolor '#00aa00' echo moo2 > file f commit -m 3 f ui -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Compressed >>> uncompressed size
In a couple of my repositories (sorry, I can't share them), /artifact_stats shows artifact compressed sizes far larger than uncompressed sizes. For example, in the one I'm looking at right now, the ALL uncompressed size is 188,230,318, but the compressed size is: 262,107,865,366,396,928 That's a compression ratio of 139,248,484,596.619%. My tag uncompressed size is 13,628, versus the compressed size: 50,281,182,134,272 With a ratio of 368,954,961,360.9627%. That's even worse! I have a good mix of full-text and delta artifacts. Unsurprisingly, tag and cluster have zero delta artifacts, whereas manifest has 10:1 delta to full-text and file has 6:5 delta to full-text. Tested using fossil version 2.6 [7ac88481a6] 2018-06-07 00:45:54 UTC, plus I saw it in 2.5. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Markdown in tickets
Is there a reason why Fossil tickets don't allow markdown? The format options are wiki, HTML, plain text, and [links only]. -- Andy Goth | ___ 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] `unversioned' questions
I think the next project that needs this feature should write a utility script for themselves that uses the uv commands to extract files however makes sense for them. This live experimentation is necessary to figure what is needed in practice. No one is forced to wait for any changes to be made to Fossil itself. One day, a set of best practices (i.e., a vague consensus on which compromises and heuristics most people can live with most of the time) will emerge, at which point Fossil can adopt them as useful defaults, but people should always be able to write new scripts that work best for their specific projects. On 06/26/18 10:31, Richard Hipp wrote: My thought was to provide a new setting (perhaps versionable) that specified a directory relative to the root of the check-out into which unversioned files are written whenever one does "fossil update" or "fossil checkout". If the setting is missing or empty, then Fossil works as it does now. If you turn on the setting, though, then the unversioned files work just like other files in the check-out, except that Fossil never records their history. I overall like the idea, but I can envision an endless stream of feature creep as people want to do any of the following and more: - Deal with files having platform-incompatible names (slashes, backslashes, drive letters, characters unsupported by the filesystem) - Extract only files within certain size ranges - Extract only files within certain date ranges - Extract only files matching certain glob patterns - Update the unversioned files when checking in - Get diffs showing which unversioned files have changed - Handle new files being added to the unversioned directory - Reverse filename mapping done for platform compatibility when checking in or adding new unversioned files - Selectively check in unversioned files along with the rest of the check-in And on it goes. All of the above can be done today via shell scripts, so projects wanting to experiment are invited to get started right away. -- Andy Goth | ___ 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] Markdown in tickets
On 06/26/18 11:05, Richard Hipp wrote: On 6/26/18, Andy Goth wrote: Is there a reason why Fossil tickets don't allow markdown? The format options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. I apologize, I was unclear. When I was talking about Fossil tickets, I was referring specifically to Fossil's own tickets, rather than tickets in general. Right now I can't use Markdown when writing a ticket (or comment thereto) against Fossil itself. Perhaps you are asking for Markdown support to be added to the default configuration? I don't see a reason to disable it by default. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Meta-enhancement
Over the past several years I've been accumulating a long and growing list of Fossil ideas, enhancement requests, and bug reports, and it's not productive to keep them to myself, especially since it's been ages since I've had enough free time to meaningfully contribute code. But I've also not wanted to flood the list with every little pet project that comes into my head, so keep my ideas to myself is what I've done. I'm considering making a Fossil wiki page to collect it all, but the Fossil wiki is largely inactive and not conducive to discussion. A forum might be nice, but I don't want to have to enhance Fossil just to be able to discuss enhancing Fossil! It might seem the thing to do is create a bunch of tickets so each idea can be tracked, but there haven't been any Fossil ticket changes since the end of 2015, so clearly that's not been the preferred practice. Instead we've done all our discussion via email and have had very little formal development process. But were I to dump all my ideas onto the mailing list, surely most of them would get lost. Tickets are supposed to be the solution to that problem, except it appears we've been ignoring them. My next instinct is to use the Fossil wiki. Create a wiki page that lists the original ideas, gives a summary of their current status, and links to their threads in the mailing list archive. This gives a way to see all ideas quickly, know where they stand, judge them in the context of the other ideas, and drill down to the code and discussion as desired. Reviewing the wiki page list, I see there are not many pages, and most of them cover the same subject: ideas, enhancement requests, bugs. Perhaps the time has come to refactor the wiki and clean up obsolete requests and reports, instead of adding yet another page to an uncurated pile. And yet, keeping that wiki page up-to-date is a manual process that the ticket tracker system is supposed to handle automatically. Furthermore, check-ins can reference tickets more easily and stably than they can wiki pages; just do so on at least the first check-in of each branch as well as on check-ins/merges to trunk. Tickets are also more appropriate than wiki pages for capturing a discussion. But email is better yet, allowing for branching conversations, provided people make correct use of reply so threads stay together. (A forum would be help with that last problem, plus could more easily and permanently be linked to/from other areas of the repository.) Or, do both. All three, really, since I'm biased against any approach that doesn't include email since that's where the lively discussion occurs. The wiki page would index and summarize the ideas and provide links to tickets. Yes, this would be kept up manually, but it would be a little more visible than the current ticket situation. Maybe this is just a transitional phase marking the first step in a cultural shift. We'll see. The tickets would link to mailing list threads, as well as be linked to by check-ins, and would track status, assignment, finer implementation details. The mailing list would be where all the talk happens, all the philosophy about which ideas are worthwhile, how to make them better, who will benefit from them, when to tackle them, who is going to handle them, how they interact with other things, how they will end up being used in practice, and all that free-form stuff that would clog a wiki and would never fit in the rigid linear structure of a ticket. -- Andy Goth | ___ 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] Meta-enhancement
On 06/26/18 12:42, Richard Hipp wrote: On 6/26/18, Andy Goth wrote: A forum might be nice, but I don't want to have to enhance Fossil just to be able to discuss enhancing Fossil! Initial prototypes for the forum code are already in the tree. It just needs some more work. I noticed! Thank you. The recent email notification enhancements were made in order to support ongoing Forum development. I figured that's why you were doing it, and I thought it was very clever to recognize that email is useful for more than just forum integration. So even if forums end up dropped, we'll still have a major benefit for having made the attempt. Patience, grasshopper. Naturally. But even with forums in place, I think there's benefit to putting the existing Fossil ticket and wiki systems back in service. Email/forums, tickets, and wiki individually serve different goals, but they can be used together to implement a workflow management system. Though in a sense, wiki is the odd man out. With good email/forums and tickets, wiki isn't really necessary, but nevertheless wiki is commonly used as an informal replacement for email/forums and tickets. -- Andy Goth | ___ 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] `unversioned' questions
On 06/26/18 12:10, sky5w...@gmail.com wrote: My repo's were built prior to the unversioned feature, so I have not used this yet. And there is no benefit to migrating my candidate files to unversioned since their history will remain in the repo without complex shunning. But now I am confused by this thread? If/When I add unversioned files, are their original paths stripped? Are they stored differently than source code? ../dev/src/myapp/bla*.c ../dev/src/lib/bla*.c ../dev/img/bla*.png <-- unversioned ../dev/exe/myapp.exe <-- unversioned Do unversioned files remain in their relative paths at inception? Unversioned files just associate a name with contents. There are restrictions on the name. But when you extract, you have to specify where you want to extract to, which can be stdout or an editor program. http://fossil-scm.org/index.html/artifact/d3ad1bea31672b94?ln=689-773 http://fossil-scm.org/index.html/artifact/43ca4a3045902238?ln=296-308 http://fossil-scm.org/index.html/help/uv -- Andy Goth | ___ 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] `unversioned' questions
On 06/27/18 03:50, j. van den hoff wrote: but doing it via shell commands remains a hack/workaround. fossil providing functionality to treat uv-files and tracked files mostly on equal footing during ci/co/up/push/pull/sync (considering, of course, that there is no history/no deltas for uv-files) would be much better. You can set the ignore-glob to make Fossil's versioned commands ignore the unversioned files. -- Andy Goth | ___ 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] Meta-enhancement
On 06/27/18 11:37, Richard Hipp wrote: My impression is that I would be troubled by the thousands of open feature requests that the ticket system would be carrying around. But perhaps that is just a personal bias that I need to overcome. Would you be okay with me creating feature requests to track my own Fossil development ideas, or would you prefer I keep them in wiki pages or somewhere else? -- Andy Goth | ___ 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] Meta-enhancement
On 06/27/18 11:43, Richard Hipp wrote: On 6/27/18, Andy Goth wrote: Would you be okay with me creating feature requests to track my own Fossil development ideas, or would you prefer I keep them in wiki pages or somewhere else? I prefer them on this mailing list for now. What advantage do you hope to gain from moving feature requests to tickets and/or wiki? I don't fully know. I'm trying to explore alternatives right now, in this thread. That's why I started it. My concern about putting everything in email is I have too much accumulated to dump all at once, and I wanted a way to not lose track. Instead my thought was to archive it all somewhere permanent then open individual items for discussion in the order I want to talk about and possibly implement them. Then I can later see what I've covered and what I haven't and choose new topics, time permitting, or reconsider in light of other developments, all the while keeping track of the thought process. The discussion would be predominantly on this mailing list, but it would be indexed and summarized by the ticket tracker. Others can do the same thing and independently pick from the list of open feature requests (also bugs, I have those to report as well) to write/code about even if I haven't written emails about them yet. Plus, check-ins can reference tickets quite a bit more easily than they can reference emails, and check-ins show backreferences from tickets but of course not from emails. I also thought about (and wrote about) additionally having a wiki page to group all my ideas and bug reports together, but honestly the ticket tracker's report capability can already do that. Returning to the wording of your original question: "moving feature requests". I do not propose to "move" at all. Discussion would still continue on this mailing list, same as always, and in the vast majority of cases it's fine for the first mention of an idea to be in an email. The ticket tracker (or wiki) wouldn't become the new, preferred place to talk about ideas, only a means to keep track of the overall collection. But since I have a big pile of ideas, I can't dump them all at once on the list, so instead I'd create tickets, marked as enhancement (sometimes bug), with general descriptions. And there they would sit idle until someone (me) writes an email about them to the list, whereupon discussion commences. I'd then add ticket comments linking to the list archives. Then, should implementation occur, we include ticket numbers in the initial branch check-ins and the merges to trunk so that everything be cross referenced. Thus, the ticket tracker and wiki don't get pressed into forum duty, since email is already handling that for us. The ticket tracker would track tickets, with discussion limited to highly technical comments directly targeted to the implementation. The wiki would hold documents of the sort that can be versioned independently of the project. -- Andy Goth | ___ 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] email testing - no subscriber table?
On 06/24/18 05:27, j. van den hoff wrote: additionally, mabye shorten the footer separation line to exactly two `--', treating the footer as the sender's "affiliation/identity" (which usually leads to a less prominent display by the email client). If you're talking about email signatures, they are preceded by the magic character sequence dash-dash-space-newline. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Reparent problems
Even with the latest Fossil, I'm continuing to have problems with reparent. I'm also continuing to fail to produce a repeatable test case or even a repository I can share without endangering my livelihood. I've been trying for a couple years now, ever since reparent was first introduced. One would think a problem would be more likely to show itself in a stress test than in casual use, but here it's the opposite. A real Heisenbug. Today I resigned myself to the notion that I have to debug it on my own. I did find something, but I'm not sure it's even the issue I started out looking for, same as occurred recently for two issues with changing dates. I'm getting missing events in the database following rebuild or reconstruct, but the manifests and plinks and mlinks are all there. This results in holes in the timeline. I'm guessing the culprit is the test to only create the check-in event if there are no mlinks yet. Depending on artifact visitation order, this assumption might not work out too well. If the reparent tag is handled before the original check-in, will its event be created? ___ 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] Reparent problems
I tested a bit more by bypassing the mlink existence check for the artifacts I know to be affected. This resulted in the events being created but the reparents being ineffective. Artificial conditions, I know, but this reproduces the symptoms of my original problem. It looks like there are three cases: 1. Manifest artifact is visited first, at which point its event is created. Reparent tag artifact is visited later, successfully updating the plink table. All is well. 2. Reparent tag artifact is visited first, and mlink and plink are updated, but no event is created. Manifest artifact is visited later, but since it's already in mlink, no event is created. Check-in is not visible in the tree. 3. Reparent tag artifact is visited first, and plink are updated, but no event is created. Since there happen to be no (changed?) files, no mlink is created. Manifest artifact is visited later, and since there's no mlink, the event is created. However, the plink table is updated using only the P card in the original manifest, undoing the reparent tag. Check-in is visible in the tree but has the wrong parent. On Wed, Jun 20, 2018, 21:38 Andy Goth wrote: > Even with the latest Fossil, I'm continuing to have problems with > reparent. I'm also continuing to fail to produce a repeatable test case or > even a repository I can share without endangering my livelihood. I've been > trying for a couple years now, ever since reparent was first introduced. > One would think a problem would be more likely to show itself in a stress > test than in casual use, but here it's the opposite. A real Heisenbug. > > Today I resigned myself to the notion that I have to debug it on my own. I > did find something, but I'm not sure it's even the issue I started out > looking for, same as occurred recently for two issues with changing dates. > > I'm getting missing events in the database following rebuild or > reconstruct, but the manifests and plinks and mlinks are all there. This > results in holes in the timeline. I'm guessing the culprit is the test to > only create the check-in event if there are no mlinks yet. Depending on > artifact visitation order, this assumption might not work out too well. If > the reparent tag is handled before the original check-in, will its event be > created? > ___ 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] Markdown wiki relative links
On 07/04/18 16:01, Stephan Beal wrote: Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ Well, I totally forgot slashes could be in page names. What about %2f? -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Markdown wiki relative links
To create a link in the Markdown wiki, the syntax is [like this](url). That's all well and good, but what precisely does url need to be for one page to link to another? In writing embedded documentation, I've gotten used to relative paths, so in order to link /doc/trunk/doc/foo.md to /doc/trunk/doc/bar.md, I write (bar.md). However, with the wiki, there's an issue. Most (if not all) of the links into the wiki use the ...?name=page syntax rather than the theoretically equivalent .../page syntax. This throws off relative paths entirely. Relative links between wiki pages will be different depending on which "equivalent" syntax was used to access the wiki. Suppose wiki page foo wants to link to wiki page bar. If foo was accessed as wiki?name=foo, then it must link to (wiki?name=bar) or (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), which it what I hoped would work all along. To make intra-wiki links work regardless of which syntax is used to access the wiki, it appears it's necessary to use "absolute" (actually relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). This is not something I've had to deal with (yet?) when doing embedded documentation. My preference would be for Fossil to never send the name query parameter to the user. If a name query parameter is received from the user, I think maybe Fossil should not call the webpage function (other than confirming that one exists) and instead immediately send a 301 Moved Permanently back to the user to rewrite the URL to use /. Or maybe I'm missing something fundamental here. There's one other style of relative link I'll mention: (?name=bar). This replaces the name query parameter. I don't think this would work very well if linked from /wiki/foo. Also it gets even weirder when clicking a link in the preview shown by wikiedit, since it takes the user to the editor for the target page. But this last would still occur should we replace all ?name= with /. To avoid that, the link would have to be either (/wiki/bar) or (../wiki/bar), though of course that last one combines the worst of all worlds. For now, I'll make sure all my wiki links are to /wiki/whatever. Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's what Chiselapp uses. -- Andy Goth | ___ 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] Markdown wiki relative links
On 07/04/18 16:37, Stephan Beal wrote: i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) Fossil already does apply different semantics. It's simple, but not what you're thinking: As far as I can tell, Fossil rejects URLs containing %xx in the path. Sounds like a good way to avoid people sneaking metacharacters past security filters. Wouldn't want %2e%2e%2f to come up as ../ allowing you to see files outside of the document root! -- Andy Goth | ___ 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] Markdown wiki relative links
Sure, a name like /wiki/a/b could be interpreted as /wiki?name=a/b, but it would still break relative paths. It's not enough for Fossil to understand that the / in a/b isn't a path separator; the browser would need to understand that as well. Linking to (c) would either go to /wiki/a/c or /c, but not /wiki/c. On Thu, Jul 5, 2018, 02:30 Dominique Devienne wrote: > On Wed, Jul 4, 2018 at 11:37 PM Stephan Beal > wrote: > >> i don't _think_ that you can use %2f in a path component and have it >> apply different semantics than a slash. How would software know to >> differentiate between the two? That would be similar to expecting a local >> file name of a\/b to work. (If it did work, it would cause no end of >> confusion.) >> > > Sure. The slash(es) would be part of the URL. > But it's the job of the "URL router" to figure it out. > > There's likely a known prefix for wiki pages, so the URL's subpart after > that prefix > can be interpreted as a "name", as is. > > It's definitely not "usual" to route a URL that way, but it certainly > possible IMHO. --DD > ___ > 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] New Fossil user experiences
I'm working on a project with a new Fossil user. Right now it's just the two of us. He was able to create the Fossil repository on Chiselapp without any fuss, but since then it's been all my work, aside from his wiki edits. Until today. Now is the first time he tried cloning the repository onto his computer and checking in edits. With his permission, I'm going to share some of his experiences here. The first thing he said was "Got fossil ui working. Added, merged and committed website_design.md." I thought it interesting that he spoke of merging as if it were a distinct task in the workflow for adding a file. Then a bit later, regarding that same file: "Ah, I'm seeing this would be better suited as an addition to the roadmap [a separate document]. I'm reading the best practice for fossil is to leave the deprecated .md in place?" I'm not sure where he got the idea that it's best to not delete files, but he did. Maybe I should ask. I explained to him a bit about fossil changes, commit, rm, extras, etc. "'fossil changes' lists all the changes that will be committed the next time you do a 'fossil commit'. By default, 'fossil rm' doesn't delete the file from disk, only marks it to be removed in the next commit. It'll still stay on disk until you delete the file for real. People don't much like this behavior, but it's what we have, and it can be changed." Regarding fossil changes, he said, "If I get a carriage return/new line with no prompt, does that mean there are no changes to apply?" So there seems to be a bit of confusion, or at least hesitancy, about fossil changes (probably also fossil extras) printing nothing. Then the big challenge: "I've been trying to get the file removed from the online repo, ran fossil rm here and now am having difficulty committing." We went around on this for a while until I was able to correctly guess that he had typed "fossil sync website_design.md" in order to "sync" the file to Chiselapp. This was easily fixed with fossil remote-url. He said, "okay, I want to remove website_design.md and sync." I responded, "Type 'fossil rm -hard website_design.md' and 'fossil commit'. The '-hard' will go ahead and delete the file from disk for you. I can change the default to do that all the time if you like, since that's what people usually expect." He said, "Yes please." From that, I take it that the default of not deleting the file from disk is confusing to new users. As for me, "I've gotten used to just typing '-hard'." I then looked at the history and found that he actually added and deleted website_design.md twice. He explained, "Yes, I was trying to work off of a git tutorials as I had found the Fossil resources to be a bit more sparse. Even after removing a file you run git add to apply those changes." Interesting. At that point I asked his permission to share and if he had anything to add. His advice: "Take it a bit further with the quick start tutorial. Past the point of cloning or initing I'd like to have a step by step through adding, commits, and how the auto feature changes the experience from git or how it works in general." I pointed him to the /md_rules page, and he said, "This will come in handy, thank you." So perhaps we could do better highlighting the resources we already have. Lastly, a technical problem. I have a markdown document with an image in it, but it wasn't showing up for him. The solution was to look at it using /doc since /artifact was preventing the relative URL from resolving to a usable resource. -- Andy Goth | ___ 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] New Fossil user experiences
On 07/11/18 16:10, Warren Young wrote: On Jul 10, 2018, at 8:58 PM, Andy Goth wrote: I thought it interesting that he spoke of merging as if it were a distinct task in the workflow for adding a file. Did he check the file in on a branch and then merge it down to trunk? No he did not, but after reading my email to this list, he told me he said merge because his git habit is to always work on a branch. I took that as an opening to discuss the difference between git and Fossil branches. "...I'm reading the best practice for fossil is to leave the deprecated .md in place?" I'm not sure where he got the idea that it's best to not delete files It’s not Fossil-specific at all: once publicized, a URL should never die, else you get broken links, if only from web crawlers that saw that document once upon a time and then continue to return it in search results. Ah, that makes sense. Except, our project is private, and at the moment the two of us are the only ones with logins. Only the front page and the wiki are public, and I've been migrating most of our wiki stuff to the private areas because in my opinion it gives away too much secret sauce. Probably not worth shunning wiki history though. "People don't much like this behavior, but it's what we have, and it can be changed." Did you make it clear that "it can be changed" means your codeveloper can change it on his end, as opposed to waiting for someone to get around to changing Fossil for him? Yes, I told him the command to type to change the setting. Though at the time I was stupidly hoping that it was a versionable setting, in which case I could change it for him. Of course it's not, and I'm not asking for it to become one. Two weeks ago, Fossil trunk was changed so that you no longer need to reconfigure Fossil’s checkout tree to enable this: http://fossil-scm.org/index.html/info/27e5e5ce65262f5a I told him the binary he downloaded from the website probably wouldn't have the ability to change the setting on the fly and that I might have to provide him with more current binaries. Though I'll have to leave it to him to make his own macOS binary, since I'm only set up to build for Linux and Windows at the moment. (He uses macOS and Windows.) Regarding fossil changes, he said, "If I get a carriage return/new line with no prompt, does that mean there are no changes to apply?" So there seems to be a bit of confusion, or at least hesitancy, about fossil changes (probably also fossil extras) printing nothing. That’s not a Fossil issue, it’s a Unix vs Windows issue: traditionally-designed Unix programs often do their work silently if no problem occurs and there is nothing to tell the user. I am well aware. I'm just reporting new user experience. It really does drive me nuts when programs have a special case to report nothing since half the time I've got them talking to other programs (rather than a human) and I need to put in a matching special case to not treat "no changes found" as the name of a file being changed. fossil sync website_design.md That the sync command stores the given URL blindly here seems like a UX bug to me. Just as Fossil re-prompts for a password until it gets one that works, it should not store the URL until it successfully uses the given one to sync the local repo. Very good point. And if we really do want to force the URL, for example in the rare case that the system is being prepared for remote sync'ing but the network or server isn't immediately available, that's what "fossil remote-url" is for. This was easily fixed with fossil remote-url. I’d have told your codeveloper to use “fossil sync URL” here instead, so he could compare and contrast the incorrect and correct forms of the command. Hmm, right. Good point. By giving him a different command to back out, he may now be afraid to use “fossil sync” entirely. I already told him he should never need to use "fossil sync" manually. We've not gotten to the point of using any of the commands that don't sync on their own. He's no dummy. He's just trying to come out of the git fog. the default of not deleting the file from disk is confusing to new users. Yes, well, the argument’s been had for years here. I take the recent change on Fossil trunk as a sign that *eventually* the default will change. We shall wee. Nice typo. ;^) -- Andy Goth | ___ 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] New Fossil user experiences
On 07/13/18 12:23, Warren Young wrote: In my public Fossil projects, the policy is that any checkin that is potentially destabilizing should be done on a branch, as should any coherent line of work that will require multiple checkins to complete. Trunk is ideally stable at all times, so as long as a checkin is self-contained and trunk remains as stable as before, direct checkins to trunk are fine. That's a good policy, though in this situation all his check-ins have been project planning documentation. The code is my responsibility at this point. Also there's no worry about destabilization because we aren't stable to begin with. Once we have a working platform, I do plan to institute a policy like yours. If your codeveloper is remote from you, I recommend that you relieve Fossil of the burden of providing the capital-S security for your project, laying that off on SSH or some VPN technology you trust instead. If the guy with the money believes Chiselapp's security is good enough for him, it's good enough for me, especially since I'd have made it fully public if it were entirely my decision. I just didn't want to put implementation details in a section that's expressly public. For a different paid project much more strongly commercial in nature, I hosted Fossil myself to avoid trusting Chiselapp or any other such public host. 350MHz Pentium II with 256 megabytes RAM, by the way. For off-site backups of private repositories, I use the attached script. Technically it violates my rule not to put private data on publicly-accessible servers, but I trust AES, gpg, and my key to turn that repository data into a blob of useless noise to anyone without the key. Thanks. I may have need of that at some point. I'll have to leave it to him to make his own macOS binary Here’s the current trunk, built a couple of hours ago on a macOS 10.13.6 system: https://drive.google.com/open?id=1Pl3XQAVtJOv-LXTlZmPyP_tkNML9YJDa It appears to be linked to the Homebrew version of OpenSSL, so he’ll need to have that installed to run it. Not up to me. I don't have macOS anywhere at home or at work. We used to have some vendor-supplied Mac Minis, but I think they were running Linux anyway. There are two fairly common cases where he may need to sync manually: 1. Fossil UI -> edit wiki. 2. Ditto, but with tickets. True, though he has just used Chiselapp directly so far, and is now focusing on checked-in documents instead. I'll have to remind him about the doc/ckout feature so he can preview his changes. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Chiselapp status
Whom should I be talking to regarding Chiselapp questions? I want to know if there's a reason why it uses Fossil version 2.1 [83e3445f67] and if there are any plans to upgrade. I've not gotten any email replies from Roy Keene in a long time, neither regarding Tcl nor Chiselapp, though I know he's out there because of recent commits to his kitcreator project. Perhaps I just don't have the right address. -- Andy Goth | ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
