Re: [fossil-users] Minor markdown glitches
On 7/28/2017 11:41 AM, Richard Hipp wrote: On 7/28/17, Florian Balmer <florian.bal...@gmail.com> wrote: -- * The first list: ... * The second list: `|` `<` ... -- causes a crash Thanks for the bug report. Now fixed on trunk. I *really* wish that Automattic (the owners of Wordpress.com) would be as responsive as you are! I've reported a number of "quirks" and outright bugs with their implementation of Markdown for Wordpress, and have yet to receive anything more than "wait, we support Markdown?" or "Why would you use that when you can just use our wonderful hodgepodge of HTML and quirky custom extensions?" as a response. I'd add these examples to my blog post that demonstrates their bugs, but I fear what it might do... ;-) -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 version 2.3 - 10th anniversary edition
On 7/20/2017 8:14 PM, Andy Bradford wrote: I tested against ae83b2137f and it looks alright I suppose. What are ``Considered failures?'' * Final results: 5 errors out of 34965 tests * Considered failures: symlinks-dir-6 symlinks-dir-11 symlinks-dir-12 symlinks-dir-13 symlinks-dir-16 These are tests that failed, but were not expected to fail. They should be investigated, especially as they did not fail in my builds. I built on Windows 10, with GCC. Windows and symlinks are generally not friends, so I imagine you are not building on Windows? * Ignored results: 5 ignored errors out of 34965 tests * Ignored failures: merge5-sqlite3-issue stash-1-diff stash-WY-1-CODE stash-3-2 stash-3-2-show-1 These are tests that are "expected" to fail for a variety of reasons. They are marked with "knownBug" flag in the test suite. Sometimes the bug is actually in the test case. We really ought to make some time to review every use of "knownBug". If tester.tcl is invoked with the -strict flag, then tests marked knownBug that succeeded count as failures to draw attention to a known bug that got fixed. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 version 2.3 - 10th anniversary edition
On 7/12/2017 2:08 PM, Ross Berteig wrote: On 7/12/2017 11:50 AM, Richard Hipp wrote: The current plan is to release the 10th anniversary edition of Fossil, version 2.3, on 2017-07-21. I will dust off my test-maven hat and see what happens with clean builds tortured by the test suite, possibly as soon as later this afternoon. Well, I missed that target, but I did build and run the test suite against the tip of trunk, [4872a58b] . The only failure was the test pre-commit-warnings-fossil-1. That test case is sensitive to changes in the set of files in the current version of the repository, and so is unstable. A file with long lines was included in the new bootstrap skin, which changed the output of fossil test-commit-warning. I updated the reference output used in the test case, but the better long term solution is to not make test cases that are sensitive to the content of the repository. I started building sample files to stimulate various warnings a while back. That should be reviewed, and extended with the ultimate goal of removing the test that failed this time. None of that should block the planned release of fossil 2.3. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 version 2.3 - 10th anniversary edition
On 7/12/2017 11:50 AM, Richard Hipp wrote: The current plan is to release the 10th anniversary edition of Fossil, version 2.3, on 2017-07-21. I will dust off my test-maven hat and see what happens with clean builds tortured by the test suite, possibly as soon as later this afternoon. Note, however, that it is the trunk that will have been tested. For testing purposes, the latest trunk version of Fossil is running on these websites: https://www.fossil-scm.org/fossil https://www.sqlite.org/src/ http://www2.sqlite.org/src/ https://www3.sqlite.org/cgi/src https://core.tcl.tk/ -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Curiosity question: is there a recap of add/change/remove on a per-file report
On 6/18/2017 7:22 PM, The Tick wrote: Just wondering if this exists or if it would have to be scripted -- a way to get a per-file recap of added/changed/removed lines for the files in a commit. It would be a way to quickly gauge the amount of changes that had occurred. Of course there's the simple list provided by "fossil changes", but that only shows file names which changed. There's aksi "fossil diff --brief", which also only shows file names with changes. Without the --brief option, it shows the entire change, which is more than you wanted. But it does support the --checkin option which shows what changed in that particular checkin. If you configure fossil to use an external diff utility, you might be able to find one that has a summary mode that is more verbose than --brief and less complete than the usual output. The somewhat elderly GNU diff I have here on my Windows box (version 2.8.7 built in 2004 apparently) does not have such an option. Read about "fossil set diff-command" for how to do that. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] bug : /zip or /tar error page response return HTTP/1.1 200 OK
On 6/9/2017 1:26 PM, Warren Young wrote: On Jun 9, 2017, at 7:11 AM, Richard Hipp <d...@sqlite.org> wrote: Perhaps /tarball and /zip are special in the sense that they are often accessed by scripts. I don’t have any data on whether that is true, but you are right that /webpages frequently accessed by scripts should return sensible HTTP result codes. /webpages exclusively accessed from a browser can return 200 in all cases, since the only way to see the error code is to drop into the browser’s developer tools. If the error report is inline in the HTML, 200 is even arguably correct. A 404 page is almost always valid HTML, and often cleverly styled. Most browsers will show it and other status pages to the end user. But you are right that they won't show the actual HTTP status, the end user is trusting that the error page is presenting sensible information. I suppose you could argue that /zip (and /tarball) should not present text, ever. But in their normal usage by scripts, the returned content would be completely ignored unless status was 200. The JSON API should be scrupulous about returning correct HTTP result codes. The JSON API returns 200 for any result that can be best explained by a JSON result record, which itself contains a status. This is consistent with treating HTTP as the transport protocol. The HTTP transaction worked, so 200 is the correct response code, even if a parameter made the /json API endpoint not take the intended action. A code other than 200 would be correct if /json were not a valid URL at all, or if some other hard failure occurred. Other than JSON not compiled in, there aren't supposed to be very many cases where the JSON engine can't describe the situation for itself. Look at it this way. If access to /json/nosuchapi returns HTTP status 200, then the caller can expect to have a JSON document to parse. If it doesn't, then it can't expect the result contains anything parseable at all, and in general the content of a 404 page is human readable text. Given that the /json namespace is intended for use by automation that wants to consume JSON, attempting to guarantee that any access within that namespace will be HTTP 200 with a JSON packet explaining the API call results seems reasonable. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 http" doubts
On 6/9/2017 1:21 PM, Warren Young wrote: On Jun 9, 2017, at 12:17 PM, Ross Berteig <r...@cheshireeng.com> wrote: I do think that the JSON support is close to solid enough to be on by default. For functionality alone, that is surely true, but in the face of malice? Parsers are notoriously difficult to make bomb-proof. Even if the JSON API is 100% solid, it acts as an API to the rest of Fossil. Some fuzzing the JSON API might find a way to break Fossil itself, a good thing if we do it before the black hats do. I agree 100%, which is why I haven't pushed to flip the configure script option to enable JSON by default. I hope to be buying some round tuits soon. I also encourage others to build with JSON enabled and try to break it. Ideally then reducing any breaks down to a minimal sample so we can add them to the test suite for regression testing. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 http" doubts
On 6/8/2017 9:17 PM, Stephan Beal wrote: On Thu, Jun 8, 2017 at 10:43 PM, Ross Berteig <r...@cheshireeng.com <mailto:r...@cheshireeng.com>> wrote: For building tools to generally interact with a repo, take a look at the JSON support. It's (still) not compiled in by default, but builds easily if requested by ./configure --json. Trivia: the reason it's not compiled in by default is the lack of test coverage. Richard told me, way back when (2012, maybe?), that we could enable it if it had complete test coverage, including fuzz tests (making sure that random/garbage inputs/attacks don't break the repo, allow DoS, butter-overrun attacks, and similar). i never got around to doing that and am now physically incapable of doing so. Thus... if it's going to happen, someone else will have to do it :/. I created the existing JSON tests as a first step down that path. Certainly not complete coverage yet, and no fuzz testing yet. The existing tests call every documented JSON API at least once, and go to some effort to exercise more features of some than others. I put some effort into trying to trigger every documented error response code, but IIRC there were a couple that I never found a reliable way to provoke. I think fuzz testing is a great idea against all of fossil, but haven't taken the time (yet) to begin working on it. Covering all of the /webpages is probably wise. I did run the test suite over a build of fossil instrumented to measure test coverage once. There are plenty of areas where more tests are welcome. I haven't rocked the boat lately since I'm comfortable with using my own builds internally, but I do think that the JSON support is close to solid enough to be on by default. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 http" doubts
On 6/7/2017 6:42 AM, Johan Kuuse wrote: Thanks for the input. "fossil test-http" did the trick: webpage=/setup printf "GET $webpage HTTP/1.0\n\n" | fossil test-http My purposes for parsing the built-in web pages are basically two: 1. I want to hack the Fossil code: a. I parse and save the HTML from the builtin pages (excluding pages where the output makes no sense, for example /zip) b. I modify the source code (related to one or more web pages) c. I parse the same pages again to check that I have changed only the web page output I intended to change. A kind of self test before committing. This WoW is obviously only helpful for a developer changing the Fossil source code of one single (official) commit. It does not make sense to save the output for later use and compare it between commits, as the content/structure may change. Take a look at the test harness in the test folder of the repository. It's in Tcl, and has pretty good coverage of the internals despite a lack of dedicated test developers. Most of the tests drive the CLI. Even the tests for fossil json largely drive the CLI instead of /json URLs via HTTP, but there are examples in there. Naturally, I'd love to see the test suite expand to further coverage of the web face. So if you have thoughts about that, chime in here, or on the fossil-dev list where chatter about things like test harnesses won't distract the end users. For building tools to generally interact with a repo, take a look at the JSON support. It's (still) not compiled in by default, but builds easily if requested by ./configure --json. 2. I want to validate the web pages: Validate the HTML, check for broken links, etc, using for example the W3C validation tools. This kind of validation could be used both to find existing, and to avoid introducing new invalid HTML. Could possibly be useful both for programmers and for skin-makers. A test case that validates all of the HTML output would be great. That should be content agnostic, of course, so that it can be maintained without requiring a lot of work for new versions. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Webpage for multiple fossil repositories - configuration options?
On 6/5/2017 8:37 PM, Andreas Kupries wrote: I am not sure that this would help him. My reading of his request is that he wants to customize the page generated by fossil itself [1]. That was my read too. The $64K question then is where such customization would be stored. Skins are per repository, and this is running outside of all repositories. There is the global settings location, of course, but that is per user and you might (sensibly) be running that server as a daemon-like user with no actual login, and possibly even no real home directory. I suppose more command line options to fossil server is the easiest answer. Extending the very vanilla HTML emitted to optionally name a style sheet if named in a -CSS option, and to provide class documented and id attributes as appropriate, would get you most of the way. Of course, the file named as the style sheet must be automatically treated as named in the --files GLOBLIST so it can be fetched or none of this works. I'd suggest allowing a file full of TH1 code as the scripting escape to provide hooks to compute additional details per repository listed, but I'm not sure how safe that would be. Perhaps offering an option that names a collection of well-known fields to include named with single letters would be sufficient for most cases. Something like --details Lnd to also include the Logo image, the project name, and the description. There are a bunch of things in the /stat page that would sound tempting to include, but unless the stats items are cached somewhere, that could have a huge cost at the server for page fetch in a folder with a lot of repositories. Logo, name and description are all easy, and likely have a fair bit of value. Project ID is easy, but likely only interesting to us internals geeks. Age, number of commits, number of open leaves, comment of latest commit, names of open branches, owners first pet's name, are probably harder. If the --details option is used, the page could be a table and use the same sorting trick available to the ticket reports, which appears to work on any number of table columns without any coding changes. I like the idea in general. It could completely eliminate the need for cron jobs to generate an index file, without a huge amount of configuration work. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] /dev/null and /dev/urandom not available ?
On 5/13/2017 5:50 AM, Richard Hipp wrote: On 5/13/17, Olivier R. <m...@grammalecte.net> wrote: To launch the server, I simply type: fossil open repo.fossil nohup fossil server & Are you running the commands above as root? If so, Fossil will automatically put itself in a chroot jail on the directory containing the repository and drop root privileges before doing anything else. This is a security feature. If you are going into a chroot jail, probably /dev/null and /dev/urandom are no longer in that chroot jail. You can fix that by running: mkdir dev mknod dev/null c 1 3 mknod dev/urandom c 1 9 You will also probably want to put the local timezone file inside the jail, so that the server can display the timeline in server local time instead of UTC if you choose. Without that, the option "Use UTC" in /setup_timeline will have no effect. That puzzled me for a while when I first stood up a fossil on Ubuntu because there are no error messages anywhere when there is no timezone. Processes just see local time and UTC time as equivalent, silently. In that installation I'm using inetd to do the listening on a port other than 80 and launching fossil as needed. But it is launched as root, so it lands in a chroot jail. The jail is rooted at the folder containing the .fossil file (or folder of .fossil files) being served, so along with *.fossil I have dev/urandom, dev/null, and etc/localtime (which is a copy and not a symbolic link because the chroot jail won't allow the link to be followed). -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] autosetup v0.6.6 issue
On 5/11/2017 2:48 PM, Sergei Gavrikov wrote: $ echo ./configure ... | sed 's/--with-[^[:space:]]\+/&=1/g' | sh Problem is --with-openssl=/local/ssl doesn't fit that pattern. Nor does --with-zlib which also takes a variety of string values. I don't see why the author of autosetup arbitrarily decided to change the meaning of --with-x. There's no mention of that in his Git comments, nor any issue that requests the change. If it were only boolean flags, we can solve that by fixing auto.def to rename the flags without the with- prefix. But there are those pesky string valued options... And I don't want to make my build and test automation depend too much on which version it is building. That is the whole point of using autosetup! -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] autosetup v0.6.6 issue
Looks like this was broken as part of a change in handling of boolean options to autosetup. Older versions understood --enable-x and --disable-x, but in a change committed on 2016-09-11, --with-x, and --without-x were added to the list of magic prefixes. https://github.com/msteveb/autosetup/commit/576d4a1dc366f81f757dae1c3cb070eaa41e0c1b Since the options in fossil's configuration liberally use --with-thing for both strings and booleans, I don't see a non-breaking change. I know this change blocks my clean build and test automation which configures and builds fossil with a variety of configurations. On 5/11/2017 8:51 AM, Sergei Gavrikov wrote: Hi, It seems that new autosetup [c5e4100705] cannot handle properly configure options with prefixes (enable|disable|with|without). Try, please $ ./configure --with-th1-docs Host System...x86_64-unknown-linux-gnu Build System...x86_64-unknown-linux-gnu C compiler...ccache cc -g -O2 C++ compiler...ccache c++ -g -O2 Build C compiler...cc Checking for stdlib.h...ok Error: Unknown option --th1-docs Try: 'configure --help' for options Old autosetup had no such issue. Sergei ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Problem with: fossil revert -r xxx
On 5/10/2017 8:54 PM, Ron Aaron wrote: I tried to revert to a good revision 'xxx' using "fossil revert -r xxx" Despite the help stating "Revert all files if no file name is provided", instead fossil told me, "the --revision option does not work for the entire tree". The help also says "-r REVISION revert given FILE(s) back to given REVISION", which strongly implies that it can only be used with a single file at a time. But in my experience, fossil revert is a rarely used command. Each file it reverts is edited in the current workspace to have the content it did at that version. Those edits are usually changes that would subsequently need to be committed. The only time they are not, is when the revision xxx is the same version as the workspace itself; thus editing the file to put it back before you accidentally broke it with some other command. This often does make sense when you merge from the wrong branch by mistake or need to repair damage caused to a file by local uncommitted changes. But I've rarely used it. Is it possible you really wanted "fossil update xxx" instead? That would make all the changed needed on disk to move the current working copy to revision xxx. It isn't an edit. You simply have a check out at that revision level. This is a command that is frequently used to hop between trunk and branches, or to go back to a version that has a bug report to reproduce it locally in exactly the version the reporter has. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting cruft in my repos
On 5/10/2017 1:12 PM, Tony Papadimitriou wrote: So, ignore ‘makefile’? *From:* Ross Berteig <mailto:r...@cheshireeng.com> # ignore files without at least one dot somewhere in their name !*.* Yup. It would do that. And README, LICENSE, CHANGELOG. Not without its problems. But ignore-glob is just a suggestion. YOu can still say fossil add makefile and it will add it. It just won't add it by default when you say fossil addremove. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Limiting cruft in my repos
On 5/10/2017 7:08 AM, David Mason wrote: I generate the initial fossil for them. The problem is that I don't control, e.g. executable names, so if they have foo.c and say `make foo` they will have foo.o which I can match, but also foo which I can't (because they might call it foox.c - and hence foox - instead). Because I generate the initial fossil the `:::BINARY:::` pattern in the ignore-glob file is viable, as would be a `:::SizeOver:::10` pattern. Here is an example of where Windows is slightly better off. By clearly designating a binary executable as `.exe`, you can put that in the ignore-glob and be confident. Unfortunately, file globs are not regexps so you can't ignore any file without a dot in its name. But you could if we included a feature that Git has, allowing ! at the front of a glob to invert the match. If we had that (and comment lines in glob files), I think this might work: # ignore obvious build targets *.o *.d *.a *.so # ignore files without at least one dot somewhere in their name !*.* # and for Windows *.obj *.lib *.dll *.exe But that will treat "lesson.one/foo" as allowed, not ignored as you might have preferred. Having a way to use SQLite's REGEX instead of GLOB for filename matching on a case-by-case basis would also be a solution. It would allow writing a regex that excludes "lesson.one/foo", at least. Not sure what the best notation to propose for that would be, or if the REGEX operator is enabled in fossil's loaded SQLite. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] A tutorial about "branches", "trunks", "leafs", etc.?
On 4/29/2017 7:30 PM, The Tick wrote:
OK, I think I've figured it out!
You're supposed to do a fossil >open< with a version name being
"trunk" (default) or "branch name". When finished, do a fossil close.
You could do it this way, but open and close are more overhead than you
really need.
For most things (and especially for my work on fossil itself) I keep a
single working folder that was originally populated by "fossil open". I
use "fossil update branch-name" to change that folder to a specific
branch where I want to work, and "fossil update trunk" to change to the
trunk. Either way, the next "fossil commit" (without a -branch option)
commits the changes to whatever branch ("trunk" is just the default
branch) the working directory is currently on. (Also, read up on "fossil
bisect" for a command that moves the working folder to a different
revision, effectively allowing a binary search for what version
introduced a bug.)
If I notice that the changes I've made are risky, need further review,
are a mistake, or otherwise belong to a different branch that the
workspace is currently at, "fossil commit --branch new-branch-name"
creates a new branch for the changes I just made. Note that this is
truly a new branch. If the name was previously used, the timeline will
not connect this fragment to any other prior fragments with the same
name. The name "mistake" is used by convention in the fossil project to
be the branch that holds work the turned out to not be useful. Although,
it is a name usually applied by editing an existing checkin to move it
from "trunk" to "mistake" rather than by "fossil checkin --branch mistake".
For some projects where I am maintaining a version already in the hands
of users at the same time as developing new features, I occasionally
open several work folders on different branches. That allows work in
progress to be left partially finished when the urgent phone call comes
in, and for related detritus such as build artifacts to be left alone so
that you don't end up needing to do a complete clean build as punishment
for looking back at a past release just to attempt to reproduce a bug,
and then another clean build when you get back to your ongoing work.
The command I personally never use is "fossil close". It exists at all
for symmetry with "fossil open", and to clean up a database entry in
your master list of open repositories that will be subject to "fossil
all". But I've never found that to be a compelling reason to use it, and
most of the benefits of being able to say "fossil all rebuild" also
disappear if "fossil close" is used too often.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: local .fossil-ignore
On 4/18/2017 2:29 PM, rosscann...@fastmail.com wrote: @Barry: True, but it's clumsy, since you have to specify every path, in full, in the global ignore-glob file. If you move a subproject to a different location in the directory tree, you have to remember to update the ignore-glob file. No, the wild cards in the glob can match any part of the path. You can ignore "*/_build/*" and that will ignore any folder named _build and all its descendants anywhere in the tree except at the root of the workspace. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature request: local .fossil-ignore
On 4/18/2017 2:21 PM, Barry Arthur wrote: This is already possible with pathed globs in your .fossil-settings/ignore-glob file. On 19 April 2017 at 01:10, David Mason <dma...@ryerson.ca <mailto:dma...@ryerson.ca>> wrote: I have had to use Git for something this semester. It was mostly a failure and I'll find a way to use fossil going forward. That said, I noticed one feature of Git that was very useful, and I'd love to see in Fossil. In Git, you can have a .gitignore file in any directory and it applies to that directory and nested sub-directories. This is very handy, especially for build directories and executables. For example, if I have a directory where I'm working on a program foo.c, I can (and do) exclude *.o in my .ignore-glob, but I don't really want to put "foo" there because I might have a file foo in another directory that I *do* want in the repo. If I could put "foo" in a .fossil-ignore file - in that particular directory - that would be very convenient. It would also be useful in a target directory (for Rust/cargo) or a _build directory (for Elixir/mix), where the only file you'd add to the repo would be the .fossil-ignore, where you'd put "*" so that nothing would be added. It isn't well documented (yet, working on that right now) but the globs are matched against the whole pathname of each file. Also, wild cards are allowed (unlike Unix or Windows) to match path separators. This allows a number of common cases to be easily handled in the single .fossil-settings/ignore-glob file, stored alongside the other versioned settings. So a glob like "*.bak" or "*.o" works on files in the entire tree because the "*" matches the path separators, just as a glob like "*/_build/*" would match all the files in any "_build" folder below the workspace root. As long as names are reasonably unlikely to collide, that sort of glob can be set once and never need further maintenance even if you re-organize or add a second thing to build. Another thing that is not really said explicitly is that the ignore-glob setting is mostly just a suggestion to fossil. It sets the default behavior of some commands, but can usually be overridden either by naming a file explicitly on the command line or by changing the entire setting with the --ignore option to a command. Specifically, the ignore-glob is not a kind of automatic "fossil rm". I frequently include "*.dll" in my ignore-glob. If I needed to check in some specific DLL (perhaps it was provided by a vendor as a binary only) I can still say "fossil add some.dll" and then it will be picked up by the next commit. Similarly if there were some file that an IDE (stupidly) located in their build output folder that must be tracked, you could still say "fossil add tool/_build/valuable-file.txt" even with "*/_build/*" ignored. One thing that is missing is the ability to have comments in the ignore-glob to explain why some obscure file is being ignored. (Also thinking about that, there are issues, but once settled it should not be difficult.) There has been discussion in the past of the merits of a single project-wide ignore-glob vs individual files scattered in the tree. I don't recall the details, but we settled on the single file in full knowledge of it being different from other DVCS systems. I think this would be a nice little project for someone who wants to delve into the fossil codebase. I would, but I'm *way* over-committed at the moment. As usual, a working patch adds a *lot* of weight to an argument for a feature. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to deal with obsolete stuff in a repository
On 4/17/2017 7:26 PM, The Tick wrote: . So I've goofed up by putting freetype-2.7.1/ and others into the repository? "Goofed up" is too strong. "Picked a different way to do it" is more accurate. There are tradeoffs and a lot of personal preference involved. I guess I had assumed that I could just add, say, freetype-2.8 some day and change the master makefile as appropriate while making any other changes that might be necessary to accommodate the new library version. Then, I would do a commit after verifying everything still works. You certainly can do it that way. When you replace freetype-2.7.1 with freetype-2.8, just rm -rf the old one and unzip the new one. Fossil addremove will mark the entire old tree as no longer tracked and add the new tree. What you lose doing it this way is any continuity of history of files in both versions. But that might not really be a loss. There's an internal storage cost too, in that fossil might not store the new version as efficiently as it could have, but that almost never matters given today's price per byte of disk, and that source code is already highly compressible by fossil's internal use of zlib. If the library's name should not contain a version string, I guess I'd need a readme or something to tell what the current version is? I guess the commit message could mention that, but stuff gets lost in all the commit messages. You can also tag the checkin with the library version. Probably should do that anyway, it can help you locate where in the timeline you introduced a particular version. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to deal with obsolete stuff in a repository
On 4/17/2017 6:50 PM, The Tick wrote: I've put a project under fossil. Since it depends on a couple other libraries, I've also put those into the repository so that I am not dependent on being able to download those particular versions. Now, when new versions of those dependent libraries become available, I want to update my project. I could just add the new versions and modify my makefile. The problem I see is that over time the fossil repository is going to get >really< big as it will contain a bunch of obsolete stuff. Is there a way to handle this? I really want to keep the dependent libraries in the repository since who knows what might happen to someone else's open source project in the future, and in addition, it makes my project "self contained". This is essentially why the "fossil addremove" command was invented. When an upgraded library is available, do something like this: Start with your working directory clean and stable, possibly even updating back to a stable point on trunk. Unzip the new library on top of the old in your workspace. Try to avoid preserving a version number as part of the folder names in the workspace even if your upstream does that to you. That will just confuse life. Now the only change to your workspace should be the new library, so fossil addremove should be able to discover new files to add and old files to delete in the repository. If nervous, use fossil addremove --dryrun to get a preview of what it would do, and you can always check fossil changes after to see what it actually did. Now would be a good time to check in this baseline set of changes on a branch and switch to that branch. Fossil ci --branch does this for you. You should be able to build and test the library and its integration with your project, committing as you go. This is where a branch really helps, as you might discover that the upgrade is not a simple drop-in replacement and need to maintain the current version in parallel. When happy, use fossil update to switch back to trunk and fossil merge to bring the new library version and all the integration effort over to trunk. Naturally, this keeps the older versions on hand, but since they built older versions of your project, that helps keep it all straight for later maintenance and patching. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with crlf-glob *
On 4/12/2017 10:30 PM, Scott Robison wrote: On Wed, Apr 12, 2017 at 4:41 PM, Thomas <tho...@dateiliste.com> wrote: On 2017-04-12 23:24, Scott Robison wrote: When I am using the download from fossil-scm.org, I am able to use single quotes to 'escape' the asterisk. Double quotes do not work. On Windows? How'd you do that? Using a copy of fossil.exe 2.2 I just downloaded from fossil's download page a minute ago, from a command prompt on Windows 10 Pro, as follows: Interesting. That does work, but not entirely for the reason I expected. Using my build of Fossil 2.1 on Win10 64-bit, and the fossil test-echo command, I see: C:\Users\Ross\Documents\tmp\fossil4>fossil test-echo '*' g.nameOfExe = [C:\Programs\Bin\fossil.exe] argv[0] = [fossil] argv[1] = [test-echo] argv[2] = ['*'] C:\Users\Ross\Documents\tmp\fossil4>fossil test-echo * g.nameOfExe = [C:\Programs\Bin\fossil.exe] argv[0] = [fossil] argv[1] = [test-echo] argv[2] = [.all-help-9c65b5432e.html.espell] argv[3] = [.dockerignore] argv[35] = [www] So the single quotes work. The arguments are passed by CMD to fossil.exe without expanding wildcards. It appears that the single quotes prevent expansion in the C startup code, but are preserved. But that is ok, because the GLOB syntax understood by fossil allows quotes and strips them off before matching. There's one more quirk. The globber does not change the argument in fossil if no files match. I suspect that causes some confusion when experimenting with this: C:\Users\Ross\Documents\tmp\fossil4>fossil test-echo *.no-such-file.* g.nameOfExe = [C:\Programs\Bin\fossil.exe] argv[0] = [fossil] argv[1] = [test-echo] argv[2] = [*.no-such-file.*] C:\Users\Ross\Documents\tmp\fossil4> -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with crlf-glob *
On 4/12/2017 1:10 PM, Thomas wrote: I might try MinGW as soon as I figured out how to buld Fossil with MinGW/Cygwin. ;-) On Windows 10 Pro 64-bit here, I still build fossil as a 32-bit exe with MinGW because there seems to be no need for 64-bit. I use the MinGW lightweight environment provided by MSYS. I've also salted in a bunch of otherwise handy classic *nix utilities built for Windows Console by the GnuWin32 project. (Sadly that project is not well maintained, but their downloads still exist. YMMV.) From the MSYS bash prompt in an open fossil clone of fossil, I find that the standard recipe of "./configure ; make" works well to build it, as long as the right options are provided to configure. A very clean and lightweight build can be had from ./configure --with-miniz --with-openssl=none That will substitute miniz instead of zlib, which has the advantage for building that miniz is a single C file compiled and linked along with fossil. A full source kit to zlib is included in .../compat/zlib but it needs to be built separately before fossil can be configured and built with it. The big downside with using miniz in your build is that there is an issue that prevents linking both OpenSSL and miniz. I have not chased the issue down, the workaround is simply to build and use real zlib instead. If you have invested in the effort to have the correct OpenSSL available, the marginal cost of getting zlib to build is negligible. For a complete fossil with all the bells and whistles that work on windows I invoke configure as: ./configure --with-zlib=tree --with-openssl=C:/Programs/MinGW/msys/1.0/local/ssl --json --with-tcl --with-tcl-stubs --with-tcl-private-stubs --with-th1-docs --with-th1-hooks Of course, you need to point configure at the correct location for SSL. I normally build outside of the source tree, so the configure invocation is usually something like ../../fossil/configure Built this way, my builds also pass the fossil test suite available by saying make test. There are other ways to build on Windows, including using MinGW at a CMD prompt, or using Visual Studio's compiler instead. The "official" documentation is here: https://www.fossil-scm.org/index.html/doc/trunk/www/build.wiki I've been looking at the wildcard globbing from command line issue, and the bottom line is that out of the box MinGW and MSVC both defer to the Microsoft C Runtime Library to get argv[] initialized. There is a mechanism available at link time to tell it not to glob before main() is entered, but its complicated. No one is happy. Lots of shouting on mailing lists. More yak shaving and bike shedding. Also, sadly, no changes. It doesn't help that MS has been changing what they do in edge cases from release to release, making it even harder to figure out what to do to build code that does what you assume you wanted. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with ignore-glob
On 4/11/2017 3:24 PM, Thomas wrote: This is actually one of the sources I based my exclusion list on. I added other files too. I replaced all # characters at the beginning of each line with semicolons, extracted the files like [Tt]umbs.db to Thumbs.db and thumbs.db, saved it, and let my batch file create a comma-separated list for the --ignore command line switch. Which raises a documentation point. I just realized that the GLOB syntax that fossil understands is more powerful than fossil's documentation explicitly shows. The documentation is vague and only shows examples using the star wildcard. But it can do more GLOB matching is implemented[1] (like many low level constructs) by calling into SQLite. In this case, the SQLite GLOB operator is used to do the match. The SQLite documentation[2] says "The GLOB operator is similar to LIKE but uses the Unix file globbing syntax for its wildcards. Also, GLOB is case sensitive, unlike LIKE. The infix GLOB operator is implemented by calling the function glob(Y,X) and can be modified by overriding that function." It also says[3] "The glob(X,Y) function is equivalent to the expression "Y GLOB X". Note that the X and Y arguments are reversed in the glob() function relative to the infix GLOB operator. If the sqlite3_create_function() interface is used to override the glob(X,Y) function with an alternative implementation then the GLOB operator will invoke the alternative implementation." It doesn't actually define what it meant by "Unix file globbing syntax", but one could easily assume that meant the obvious use of '*' and '?'. But all Unix shells also support character classes, and some support even more features that could be lumped in with globbing (such as '~' for $HOME). Various on-line tutorials (not official SQLite documentation) say that [abc] character classes work too. I had to resort to the SQLite source to find a definitive definition[4]: Globbing rules: '*' Matches any sequence of zero or more characters. '?' Matches exactly one character. [...] Matches one character from the enclosed list of characters. [^...] Matches one character not in the enclosed list. With the [...] and [^...] matching, a ']' character can be included in the list by making it the first character after '[' or '^'. A range of characters can be specified using '-'. Example: "[a-z]" matches any single lower-case letter. To match a '-', make it the last character in the list. So the examples from the gitignore project can be used as is if comments are stripped out. Adding support for comments to the glob parser in fossil might not be that difficult, I may look into that if I get time as it is something I've wanted in the past.You mentioned changing the git comments into semicolons. I'm not sure that does anything at all in fossil. If it does, that should be documented too. Something I definitely will do (unless another developer beats me to the punch) is figure out a good place to drop the definition of what a glob can be into the documentation. There's probably more than one place that makes sense, but I don't want to repeat it in every command that mentions supporting one of the glob settings or has an option that uses a glob, so I'm looking for the sensible best place to put it. [1]: https://www.fossil-scm.org/index.html/artifact/2209933ddc94df7e [2]: https://sqlite.org/lang_expr.html [3]: https://sqlite.org/lang_corefunc.html#glob [4]: http://www.sqlite.org/src/artifact/9d52522cc8ae7f5c?ln=616-631 -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with ignore-glob
On 4/11/2017 3:24 PM, Thomas wrote: On 2017-04-11 23:09, Ross Berteig wrote: On 4/10/2017 11:48 AM, Thomas wrote: Actually, I got a batch file that reads the file filter settings from another file and creates the binary-glob and the ignore-glob files on the fly before an addremove and a commit (crlf-glob is not created and only contains an asterisk now). Why do this on every commit? That's a legit question. The reason is that at first I only learned about the command line swiches, that take the list comma separated. My files however contained a mask on each line, basically the same way the .fossil-settings files are outlined. I only learned about the .fossil-settings folder later here in the mailing list, hence I just quickly changed the batch file to create the required files. The reason why I had my files in this format is because I assembled my lists from sources on the web with common file name extensions, file and folder names. The whole point of the versioned settings is that they can be set once and stored, and are carried with the repository into every working folder on fossil open. The only differences to my file is that it's got a different filename extension for which Notepad++ allows me to insert syntax-highlighted coments, and that it sorts the list. That's all. You figure out what files never need saving, and put globs in ignore-glob that match them. Note that the globs are matched on the whole pathname in the working folder, so you can exclude entire folders too if that is handy. Which is nice for things like the Release and Debug folders that VS tends to create in its projects. You will want to work out carefully what files your IDE needs to be treated like source code, which of those are binary (a stupid mistake made by too many IDEs is to use binary files for project configuration which makes using version control harder than necessary), and which files are build products. Something like this is my usual starting point for ignore-glob for a lot of projects. I usually create ignore-glob right after creating the repository and before checking things in. I always include globs for whatever backup files get created by my text editors, all the build products I can identify, and if practical, any folders created by building. ~*,*.bak *.o,*.d *.obj,*.exe,*.dll *.bin,*.hex *Build*/* *build*/* ship/* *.zip,*.tar* The fossil extras command is useful for finding things that belong in ignore-glob. It lists the files that fossil addremove would add or fossil clean would delete. IDEs come with an extra burden. They always seem to be written by people that believe there is no world outside of the IDE, and especially no version control. Worse, they also seem to be hostile to all the other IDE developers, and highly resistant to any sort of standardized naming of things. On the positive side, there is this project at Github where people are tracking what to tell Git to ignore. The syntax isn't identical for fossil, but the data is still valuable. https://github.com/github/gitignore This is actually one of the sources I based my exclusion list on. I added other files too. I replaced all # characters at the beginning of each line with semicolons, extracted the files like [Tt]umbs.db to Thumbs.db and thumbs.db, saved it, and let my batch file create a comma-separated list for the --ignore command line switch. My key point here is that this is a one-time setup for a repository. Possibly a second time when you discover something you missed, or add a new tool to the project. Not something you should need to edit constantly. I've been using fossil for years with projects in C and Lua, for many different target architectures, with and without several IDEs, and even for documentation-only projects with text in Markdown or LaTeX where builds produce PDFs. I essentially never use fossil addremove. It is not part of my workflow at all. I do use fossil extras and fossil changed as part of my habitual review before I commit changes. The extras command tells me if I forgot about a new file. The changes command tells me what files I actually changed. In both cases, I want to know that I'm not committing large swaths of unexpected files. To my mind, addremove is simply too powerful since it assumes that missing and new files are intentionally missing and new. That means that fossil addremove will also mis-handle a renamed file, which would otherwise be correctly handled by using fossil mv to tell fossil the file changed names. I actually almost never use fossil clean for much the same reason: it is too powerful, I don't want it breaking my IDE just because after a tool upgrade it suddenly is writing some new intermediate file I hadn't yet heard of. I tune the ignore-glob based on what fossil extras is saying, generally aiming for extras to be an empty list. I always use .fossil-settings for complex settings like the various globs. It is too
Re: [fossil-users] Issue with ignore-glob
On 4/10/2017 11:48 AM, Thomas wrote: Actually, I got a batch file that reads the file filter settings from another file and creates the binary-glob and the ignore-glob files on the fly before an addremove and a commit (crlf-glob is not created and only contains an asterisk now). Why do this on every commit? The whole point of the versioned settings is that they can be set once and stored, and are carried with the repository into every working folder on fossil open. You figure out what files never need saving, and put globs in ignore-glob that match them. Note that the globs are matched on the whole pathname in the working folder, so you can exclude entire folders too if that is handy. Which is nice for things like the Release and Debug folders that VS tends to create in its projects. You will want to work out carefully what files your IDE needs to be treated like source code, which of those are binary (a stupid mistake made by too many IDEs is to use binary files for project configuration which makes using version control harder than necessary), and which files are build products. Something like this is my usual starting point for ignore-glob for a lot of projects. I usually create ignore-glob right after creating the repository and before checking things in. I always include globs for whatever backup files get created by my text editors, all the build products I can identify, and if practical, any folders created by building. ~*,*.bak *.o,*.d *.obj,*.exe,*.dll *.bin,*.hex *Build*/* *build*/* ship/* *.zip,*.tar* The fossil extras command is useful for finding things that belong in ignore-glob. It lists the files that fossil addremove would add or fossil clean would delete. IDEs come with an extra burden. They always seem to be written by people that believe there is no world outside of the IDE, and especially no version control. Worse, they also seem to be hostile to all the other IDE developers, and highly resistant to any sort of standardized naming of things. On the positive side, there is this project at Github where people are tracking what to tell Git to ignore. The syntax isn't identical for fossil, but the data is still valuable. https://github.com/github/gitignore Now I wonder how hard it would be to add support for comments to fossil's versioned settings files, as well as the [Aa] to the globs. Comments are probably easy, but I suspect the glob syntax is tied to SQLite. I may look into that. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with ignore-glob
On 4/11/2017 9:36 AM, Thomas wrote: I would like to emphasise that --ignore (or .fossil-settings\ignore-glob) is an _explicit_ command, clearly stating the user's desire for exlusion of these files, following the documentation. Silently ignoring this wish can't be the correct process. But that isn't what the --ignore switch (and globs) means. It means ignore these files in this command's invocation. That generally has nothing to do with what fossil will do with files that are already in the repository. To stop tracking revisions of a file that is checked in, you must ask fossil to do that explicitly. There are two ways to achieve that: 1. fossil rm somefile 2. rm somefile && fossil addremove The fossil rm command marks the file as deleted as of a specific checkin, which is also on a specific branch. That is, the removal is itself versioned. This is the proper way to remove a source file that is no longer needed. It disappears from this branch and all descendants, but not from any other branch, or from the past. (Fossil rm can also be used to reverse an unintended fossil add *before* it is checked in. In this case, it operates on the working checkout only. But the intent is the same.) Generally fossil rm only acts on the repository, but there has been discussion of whether not also deleting the file from disk is or is not surprising to a user. So there is a setting that changes the default, and a command line option that forces it to also delete from disk. There is also a near-synonym "forget" that will never delete from disk. See fossil help rm for all the gory details. The fossil addremove command is a convenience command that scans the tree, obeying some of the glob settings, and applies fossil add and fossil forget command as needed to make the list of files now in the repository consistent with the settings and the directory tree in the working checkout. Knowing a subfolder is currently a mess, you can freely say fossil addremove --ignore mymessypart without meaning anything more or less than do the addremove operation except in that folder right now. A switch that doesn't work is either a huge design flaw or a bug. A --ignore switch that doesn't ignore is a huge security bug (and a trap) too. What would I need a --ignore switch for when I got to delete the files first manually anyway? That's completely contrary to its purpose, isn't it? The reason why I'm using --ignore is because I _don't want_ to delete these files. You should use fossil forget or fossil rm to remove the files from further tracking, and set the ignore-glob (and check it in) to prevent further accidental tracking. The --ignore switch is documented to "Ignore files matching patterns from the comma separated list of glob patterns." And that is exactly what it does. The fossil addremove command does not touch those files either on disk or in the repository. It ignored them. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with crlf-glob *
On 4/8/2017 2:29 PM, Thomas wrote: Thanks for this quick reply. I think I understand it now. However, it's still quite weird. C:\fos>fossil test-echo * g.nameOfExe = [C:\fos\fossil.exe] argv[0] = [fossil] argv[1] = [test-echo] argv[2] = [_FOSSIL_] argv[3] = [fossil.exe] argv[4] = [db.fossil] argv[5] = [test.cmd] Is this what it's supposed to look like? Yes that is what fossil test-echo is supposed to do, but this shows that it expanded the * to file names. If it had been quoted right, you would have seen only entries for argv[0], argv[1], and argv[2]. Which is what I thought I saw when I did fossil test-echo "^*", but I was blinded by expectations and missed that it showed "^*" for argv[2] not "*". So that doesn't work as expected. test.cmd contains: ECHO %1 When I run it: C:\fos>test.cmd * C:\fos>ECHO * * So, it works for test.cmd but not for Fossil. Strange. Welcome to the strange and wonderful world of CMD.EXE's quoting rules. Which differ between the interactive prompt and in a .BAT file (and in some subtle ways .CMD files are yet different) too. All is documented somewhere, but hard to find. I've spent several "pleasant" hours just reading the output of CMD/?, IF/?, CALL/?, START/?, and so forth. Often, important bits of trivia are only said in the help text for an obscure built-in command. In fact, what is really happening is more complicated. The command fossil test-echo * is passed the * by CMD, but as part of the C runtime startup, it is expanding wildcards on the command line so that fossil sees what it would see on a *nix box where the shell does the wildcard expansion before any program runs. You can see this at the prompt with echo *, and echo ^* both which echo a single * character, because the echo command does not do any wildcard expansion. I think this is an almost impossible platform-specific issue to fix. Most of the time, we want wildcards expanded. Rarely, we don't. Unfortunately, you've hit one of the rare cases. There are two easy work-arounds. 1. Use fossil ui and the navigate to the settings page in the browser. That will let you change the setting from the web form. This assumes you have a browser and your firewall will allow it to talk to an arbitrary port on localhost owned by a local process. Which should all be true. 2. Use the versionable settings. Say echo * > .fossil-settings/crlf-glob then fossil add the settings file and check it in. There are harder work-arounds. 3. Use MSYS bash to have a bash prompt with its different quoting rules. With care, it is possible to use that to modify either global settings or a specific repository. 4. Use SQL to edit the setting into the repo file. Don't do this unless you know what you are doing. The hint I'll provide is that the repository is actually a SQLite database file. There is documentation. But directly poking it is dangerous, so only try on a backup. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Issue with crlf-glob *
On 4/8/2017 1:59 PM, Richard Hipp wrote: On 4/8/17, Thomas <tho...@dateiliste.com> wrote: C:\fos>fossil settings crlf-glob *.obj C:\fos> C:\fos>fossil settings crlf-glob * Usage: fossil settings ?PROPERTY? ?VALUE? ?-global? C:\fos>fossil settings crlf-glob * -global Usage: fossil settings ?PROPERTY? ?VALUE? ?-global? C:\fos>fossil settings crlf-glob "*" Usage: fossil settings ?PROPERTY? ?VALUE? ?-global? C:\fos>fossil settings crlf-glob "*" -global Usage: fossil settings ?PROPERTY? ?VALUE? ?-global? Does anyone know how to unveil the secret of getting the mentioned asterisk into the crlf-glob setting without consulting the web interface? This seems to be a windows shell thing. On unix, you would just put the * inside single-quotes: '*' - but that appears not to work on windows. I don't know the solution. A hint: You can run fossil test-echo * to see what the command-line gets expanded to by the shell. I haven't (yet) found a variation on this that does not expand the *. Anybody else? Try "^*": C:...>fossil test-echo "^*" g.nameOfExe = [C:\Programs\Bin\fossil.exe] argv[0] = [fossil] argv[1] = [test-echo] argv[2] = [^*] C:...> The caret is supposed to be CMD.EXE's quote character analogous to /bin/sh's use of \, and I thought it worked anywhere and not just inside double quotes. But a bare ^* did not do what I expected at a CMD prompt. The other trick for settings like crlf-glob is to use versionable settings for them. Then you get to edit a file rather than fighting with strange shell quoting rules. Just create the file .fossil-settings\crlf-glob in the root of your repository's workspace and put a single line in it containing the asterisk. Add the file and check it in and all should be well. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Couple of beginner questions
On 3/31/2017 2:04 PM, Shal Farley wrote: Warren wrote: > Someone brought up TECO. I don’t expect anyone’s TECO implementation > to handle UTF-8, That was me... Hmm... I was going to say in jest that the DECUS swap tapes have a version written in C, were anyone nuts enough to take a crack at it. However Google reveals that it is closer at hand than I thought - someone has already ported it to Windows, Mac and Linux: https://github.com/blakemcbride/TECOC Since I am just nuts enough and already have Git, Visual Studio, and past exposure to TECO thanks to Shal and others, I checked it out and built it on Windows 10, 64-bit. I could certainly have built it for 32-bit, but when overdoing something, there's no point in holding back. So I accidentally wrote a blog post about the experiment. https://curiouser.cheshireeng.com/2017/04/01/ancient-tools-the-teco-editor-vs-utf-8-text/ The takeaway is that, surprisingly, a 54 year old ASCII based text editor actually can edit a Unicode document stored in UTF-8. But it is not very good at it. As someone who once wrote ad-hoc utilities as TECO macros, all I can say is: No. There are languages that would be less pleasant to use for transforming text. TECO at least was designed for the purpose. And aside from a few control characters it is almost entirely oblivious to the character set in use. Since UTF-8 was designed to leave 7-bit ASCII intact, TECO will "work" on UTF-8 text with a couple of constraints. But I won't recommend you try it at home. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Couple of beginner questions
On 3/30/2017 12:35 PM, The Tick wrote: Goodness! All I wanted was to have a comment contain a copyright character. Thanks to the people who were kind enough to take the time to respond to my questions. Now my commit messages are no longer a big blob of text, my .vimrc is modified, I've gotten fossil to stop complaining about my file, and I've learned some more about the intricacies of language support. This list is one of the good ones, in my experience at least. You may not expect the thread you get, but usually you learn something about some fragment of reality you didn't expect to come up. And actual trolling is quite rare. I never meant to start another editor war -- I thought that was over when the vi vs. emacs debate finally died years ago. I didn't see a war here, just a bunch of people happy with the tools they use. Somehow I don't expect that to change soon. I started using vi back when it was still named "vi" on early BSD systems, I'm happy to see it live on. I've used a commercial emacs inspired editor on the PC since DOS 3.1 (Lugaru Epsilon, and yes it is still supported by the same people). I've used DEC's TECO on a PDP-11, and ed on System III. (And punched cards and tape too, but I'm not that old, really!) I've survived IDEs too, and generally avoid them in favor of one or the other editor when I can. I may be unusual in not being willing to enlist in the editor wars. But I've found being willing to learn to use the tool that gets the job done is more likely to get the bills paid Now its been suggested that I not only change my editor, but my keyboard, my programming language, my OS, and even to buy a new computer from a different manufacturer. While I suppose that might move the world closer to perfection, but I've been around long enough to know that will never happen. Only in jest mixed with at least a little of platform bragging where some platforms make it easier to get things right. The large part of the world stuck with MS products can and should exert some pressure to get better compliance from MS with many standards, not just Unicode. They change at glacial speeds, but they do change. A good first step would be for them to develop and support a "proper" Unicode Locale and code page for their console window. Doing that right likely means following the examples and lessons learned from the Linux community which has been blazing that trail and found (and escaped) most of the dead ends. I think it has become clear that Unicode is here to stay, and UTF-8 is the best representation of it both at rest in files and on the wire in protocols. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Couple of beginner questions
On 3/29/2017 1:05 PM, The Tick wrote: On 3/29/2017 2:36 PM, Richard Hipp wrote: Most of the world is using UTF-8 now. I'm wondering how that can be for programming language source files. I managed to put the "bom" in front of a one-line tcl script: puts "This is a copyright symbol: ©." where the '©' was previously converted to utf-8 by fossil. gvim now reads the file and renders the utf-8 '©' as a '©' notepad displays the file and renders the utf-8 '©' as '©' If a BOM encoded in UTF-8 is present, that unambiguously marks the text as UTF-8. But. As you note that is not always compatible with other uses of the file. As UTF-8 was designed to be highly compatible with ASCII, including the BOM is not usually recommended unless it is required for other reasons. VIM seems to default out of the box to Latin1 encoding which is more consistent with Windows. (More correctly, it defaults to an encoding consistent with the current Locale, which on Windows is usually Latin1 or another 8-bit codepage. Windows does support a UTF-8 codepage (aka 65001) but I've never seen that set as the system default.) You can (probably) change it to support UTF-8, but it seems to make that task as difficult as possible for a novice to the weird and subtle world of file encoding issues. My copy of VIM 8 on Win 10 Pro correctly reads UCS-2 (16-bit Unicode) files with BOMs, but proudly converts them to Latin1 for display and editing which would clearly be a bad idea if they had included characters from outside the coverage of the Latin1 codepage. Copyright and a number of other non-ASCII but otherwise ordinary symbols are included in Latin1 and work as expected. From my reading of the help file mbyte.txt, especially Section 10 Using UTF-8, you want to :set encoding utf-8 before reading the file. Your .vimrc might be a good place to do that. Another place to do that is to use a modeline in your .tcl file that tells vim to assume UTF-8. Something like # vim: set enc=utf-8 fenc=utf-8 "near" the top or bottom of the file should do the trick. The other huge caveat is that you also need to have fonts configured that cover enough Unicode Codepoints to be useful to you. I believe VIM defaults to "fixedsys" on Windows which is not a Unicode font. You will want to change to Lucida Console at least, if not to something even more programmer-friendly such as Hack[1], Source Code Pro[2], or DejaVu Sans Mono[3] with good Unicode coverage and other features useful to coding without eyestrain. [1]: http://sourcefoundry.org/hack/ [2]: http://www.adobe.com/products/type/fonts-by-adobe.html [3]: http://dejavu-fonts.org/ You may also want your console windows to understand UTF-8. If you have the console set to use an appropriate font, (I personally use Hack for both my consoles and my editors) then all you need to do is CHCP 65001 at the CMD prompt to switch to the UTF-8 codepage. >but< $ /c/Program\ Files/tcl/bin/tclsh u.tcl invalid command name "puts" while executing "puts "This is a copyright symbol: ©."" (file "k.tcl" line 1) While adding the option "-encoding utf-8" to the tclsh command line makes it work, it does not work when I double-click on the .tcl file as I have no way to set any sort of encoding option -- unless I have to make a windows shortcut for each and every .tcl file that I want to run and put the -encoding there. There is a way to do this automatically. Windows uses registry keys to associate a file extension with a logical file type, and a file type with the command to "open" it. The assoc and ftype commands provide a simpler interface to viewing and setting the needed registry keys. For ActiveTcl, I have: C:...>assoc .tcl .tcl=ActiveTclScript C:...>ftype ActiveTclScript ActiveTclScript="C:\Programs\Tcl\bin\wish86.exe" "%1" %* You can change the definition of ActiveTclScript to include -encoding utf-8 Note that would make your installation less consistent with the rest of the users, and is thus likely not the first choice for addressing this issue. So, how can one use a program source file encoded in utf-8? -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 interprets plain-text file as a binary file
On 3/27/2017 6:21 PM, Richard Hipp wrote: On 3/27/17, Ross Berteig <r...@cheshireeng.com> wrote: I believe that a line is too long if it is more than about 8191 ASCII characters, a restriction based on the size of the buffer used in the diff engine. Technically, that restriction is due to the way hashes are computed on individual lines during the diff. For diffing, the file is broken up into individual lines, and every line is given a 32-bit hash that helps to speed up locating the differences. The lower 13 bits of the hash are the length of the line in bytes. The upper 19 bytes are the actual hash. Interesting. I didn't read further into the code than the definition of LENGTH_MASK and the comment that describes it in diff.c. I did wonder slightly at the name of that symbol, but it was described as the length of a line so I just ran with it. In lookslike.c we have UTF16_LENGTH_MASK which is described by the comment as being the same quantity expressed for UTF16 chars. But the comment and definition don't seem to agree. Richard, take a look at https://www.fossil-scm.org/index.html/artifact?name=3ac38fafa91d274c=220-226 Line 225 would compute UTF16_LENGTH_MASK to be 13-2-1 or 10, and get 1023 for UTF16_LENGTH_MASK. But the comment says 4096 Either the code, the comment, or I are confused here. Since I'm poking at test cases for this stuff. I'll see if I can add one that probes the UTF16 line length question. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 interprets plain-text file as a binary file
On 3/27/2017 6:40 PM, Byron Sanchez wrote: That was it! I ran the command and received the output: Starts with UTF-8 BOM: no Starts with UTF-16 BOM: no Looks like UTF-8: no Has flag LOOK_NUL: yes Has flag LOOK_CR: no Has flag LOOK_LONE_CR: no Has flag LOOK_LF: yes Has flag LOOK_LONE_LF: yes Has flag LOOK_CRLF: no Has flag LOOK_LONG: no Has flag LOOK_INVALID: no Has flag LOOK_ODD: no Has flag LOOK_SHORT: no I deleted the null characters. I didn't have to address any of the other flags in my case, just the null characters. After that, fossil recognized the file as plain text again. Unexpected NUL characters in a field of normal text will definitely cause fossil to treat a file as binary. If you really do need to store a NUL byte in a text file (as some sort of delimiter, perhaps) fossil permits the over-long two byte UTF-8 encoding 0xC0 0x80 even though that is a technical violation of the UTF-8 specification. Allowing that particular over-long encoding is a common extension of UTF-8. The other flags just indicate that you have normal *nix line endings rather than CR LF endings used by DOS and Windows (and many many older systems) or the CR only endings used by older Macs. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 interprets plain-text file as a binary file
On 3/27/2017 5:44 PM, Byron Sanchez wrote: I'm tracking several plain-text files in a repository. These are emacs org-mode files. Fossil sees most of the files in this repo as normal plain-text files and as such, they can be diffed via the fossil web interface. Recently, however, fossil has started interpreting one of these org-mode files as a binary file. Now, fossil prompts with it's binary-file warning each time I update the file. In addition, this file can no longer be diffed in the web interface, since fossil believes it to be a binary file. I'm wondering what steps I should take to debug this, or if there are any common causes for this sort of thing? Very long lines perhaps or possibly unicode characters? Try the command "fossil test-looks-like-utf" to see the conditions that fossil tests for your file. That should help narrow down what to look for in the file that caused it to suddenly smell binary. It usually decides a file is binary if it has a line that is "too long", or has a NUL byte and is not UTF-16. I believe that a line is too long if it is more than about 8191 ASCII characters, a restriction based on the size of the buffer used in the diff engine. The other thing that can happen is to accidentally save a text file in an encoding other than UTF-8, with some character not included in the base 7-bit ASCII set. In my experience this was usually some accented letter from LATIN1, or a symbol such as 'µ' or '°'. Your editor will likely calmly edit and save the file, everything looks fine, but the saved file has bytes that make an invalid UTF-8 sequence. That does have a different warning message than binary data (likely "invalid UTF-8") so isn't your problem with this file. The file in question is about 3.3 megabytes in size, and as far as I am aware, a normal plain-text org-mode file. Any ideas would be very appreciated! -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default
On 3/27/2017 2:29 PM, Christophe Gouiran wrote: Someone wanting to get the list or current branch without relying on raw Fossil output could use "fossil json branch list" for that purpose. But only if fossil was configured with JSON support. Which is not configured by default, or in the pre-built binary distributions. I would argue that for scripting around fossil, JSON support should be configured and used, but that will only work for environments where it is acceptable to configure and build a fossil as needed rather than depending on upstream packages or official builds. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Using child projects/repositories effectively
On 3/21/2017 6:52 AM, Richard Hipp wrote: Apparently I checked that feature in. But I don't remember doing it. I do not use it myself and do not remember how it works. Maybe you can look at the source code and figure it out, and write up some improved documentation for us? And some test cases? Even just hints as to what scenarios are interesting, what should work, and what should not work would be helpful. That will make it easier for I (or one of the others who occasionally wear the testing hat) will add coverage of it to the test suite. As an aside, tip of trunk currently passes all the tests in the suite except one (stash-1-diff) which I marked as a known bug until I get the test case fixed. I'm actively pushing the boundaries of our test coverage hoping to document edge cases, so now is a good time to bring up features that could use more or better testing. On 3/21/17, John P. Rouillard <rouilj+fos...@cs.umb.edu> wrote: Hi Everybody: I am currently using a child project/repository as described in: http://www.fossil-scm.org/index.html/doc/trunk/www/childprojects.wiki In this child repo I have files that should not be pushed to the main repo. So my locally added files, configuration file changes etc. all happily live in the child repo. However when I do a: fossil pull --from-parent-project I usually end up forking the trunk which requires a merge to get things back in order. Is that how this is supposed to work? I was envisioning the parent project would be something more like a branch that I could merge/integrate from at will. Should I change the child project's main-branch from "trunk" to "mainline" to reserve the trunk tag for the parent project. If I should rename to mainline, I have a bunch of commits in the repo. So how do I move all the child's trunk commits to the new mainline branch and establish the mainline branch going forward? Also I would like to use fossil as the method people use to manage the software at their own sites, so understanding how to use the child project feature effectively is a big win. Thanks for any ideas on how to use this feature successfully. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Old fossil (1.29) accessing current fossil trunk?
On 3/14/2017 3:06 PM, Stefan Bellon wrote:
On Mon, 13 Mar, Ross Berteig wrote:
When fossil is configured to include JSON support it has a fossil
json command that consumes a JSON object full of command and
arguments and returns a JSON object of results. A similar feature is
available over HTTP(S) through URLs beginning with /json.
Ah, that's why I never got JSON to work. The input to the JSON support
is via JSON object as well?! I always assumed you can just use ordinary
command line and specify something like --json to tell fossil to output
the result of the command as a JSON object.
The JSON API originated as a JSON over HTTP, but a mapping between URLs
and the command line made sense for debugging. So it can be used through
the fossil json command by a fairly direct mapping from /json... URLs
used for GET and POST. HTTP POST allows the submission of a command
packet rather than fitting everything into the URL.POST data can also be
simulated from the command line, from either a file or stdin.
The output is a JSON object that contains metadata about the fossil
instance and the command success or failure, as well as the result of
the command.
The documentation is not rolled into the fossil documentation as yet.
You can find it on Google Docs: https://goo.gl/Iv8OFL
The original use cases were all of the web app flavor, hence the
emphasis on HTTP in the docs, with the CLI support more of an
after-thought. I suspect that is why a --json global option was not
considered at all.
Here's a sample of output for the timeline, limited to the latest two
checkins:
C:...>fossil json timeline checkin --limit 2
{
"fossil":"38115a0bd96c3788e36506b965f938bd31f0d0b65cf26dd7866abefb80a9a15d",
"timestamp":1489530880,
"command":"timeline/checkin",
"procTimeUs":0,
"procTimeMs":0,
"payload":{
"limit":2,
"timeline":[
{
"type":"checkin",
"uuid":"38115a0bd96c3788e36506b965f938bd31f0d0b65cf26dd7866abefb80a9a15d",
"isLeaf":true,
"timestamp":1489526151,
"user":"rberteig",
"comment":"Update hash regexp to defend
against full length SHA3 hashes.",
"parents":["f92672bda33bf86752053272ef1f7aa9de088e823b9a864877042c2b8802800b"],
"tags":["trunk"]
},
{
"type":"checkin",
"uuid":"f92672bda33bf86752053272ef1f7aa9de088e823b9a864877042c2b8802800b",
"isLeaf":false,
"timestamp":1489522870,
"user":"rberteig",
"comment":"New test case for the
Markdown bug, fixed issues with hash matching, fixed tests for the
TH1 unversioned command so they no longer depend on unversioned files
from a past release in the real repository.",
"parents":["dd41f85acf57290aba64c1f42ddeafcdf80432df80a07cea699bbb7456ff1386"],
"tags":["trunk"]
}
]
}
}
You'll notice that the SHA3 hashes simply slot in place where SHA1 had
been without the format changing.
Is there a reason that the default builds as available for download
have JSON support not enabled?
We've discussed this in the past, and there hasn't been a strong
advocate for enabling it by default. It does increase the attack surface
for fossil as CGI to some degree. Until I started writing test cases for
it, it wasn't covered at all by the internal test suite. I know the lack
of testing was a big concern. I've increased its coverage from "none" to
"some", but I can't claim that the JSON support is well covered by the
tests yet. Most features only have tests that confirm the feature is
present and got a correct answer, with no attempt to probe at edges and
errors.
Maybe it is time to bring that discussion back up.
Also, not every command is available via JSON, and I suspect that
there is no JSON equivalent to fossil annotate. If we can figure out
how to represent the annotate/blame/praise data in JSON, then adding
it should be possible.
I can tell you how JSON output of IBM Rational Team Concert (which is a
complete mess, but has wonderful JSON output) looks like for the
annotate command for a specific file:
{
"annotations": [
{
"author": "author
Re: [fossil-users] Old fossil (1.29) accessing current fossil trunk?
On 3/13/2017 8:57 AM, Richard Hipp wrote: On 3/13/17, Stefan Bellon <sbel...@sbellon.de> wrote: When upgrading from 1.24 to 1.29 years ago, the output of "fossil annotate" changed and broke all our scripts (and even some customer databases). I expect even more incompatibilities when switching from 1.29 to 2.0 and therefore this is nothing that can be done in a few minutes. We have to check for all the output of all fossil commands we use in scripts whether they still produce the same output they did before. I'm a little confused. If you need to continue using Fossil 1.29 for text output compatibility, then why is it a problem that you cannot "fossil update" to the latest trunk? After all, you won't be using the latest trunk, right? Also: What can we do to help you move away from scripts that depend on the details of command-line output and toward something that is more likely to survive an update? What are your scripts doing? Would it be better to run SQL queries directly against the repository database? Are new fixed-output-format commands needed in Fossil to extract information that is important to scripts? When fossil is configured to include JSON support it has a fossil json command that consumes a JSON object full of command and arguments and returns a JSON object of results. A similar feature is available over HTTP(S) through URLs beginning with /json. Unfortunately JSON support is not configured in the default builds of fossil. I often turn it on for my personal builds, because I have some scripts that draw from the ticket system for report writing, and the JSON support for reading and querying tickets works quite nicely. I'd personally like to see the JSON support trusted enough to be on by default. Also, not every command is available via JSON, and I suspect that there is no JSON equivalent to fossil annotate. If we can figure out how to represent the annotate/blame/praise data in JSON, then adding it should be possible. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil 2.1 upgrade path
On 3/12/2017 10:50 AM, Richard Hipp wrote: On 3/12/17, Piotr Orzechowski <fossi...@orzechowski.tech> wrote: Can I jump directly from 1.37 to 2.1? Yes. Simply download and install 2.1 and you are done. Optional seconds step: Type "fossil hash-policy sha3" in a check-out directory of any repository that you want to start using SHA3 hashes. Then next time you do a commit from that check-out, the repo will will automatically start doing all new commits as SHA3. If you do not care aboud SHA1 vs SHA3, then you can safely ignore the second step. I have a build on a x86_64 Linux box at my web host, which I bootstrapped on that box originally by building from one of the source tarballs, then cloned the fossil repo and rebuilt from the repo. My installed fossil was sitting at v1.36, and I'd like to bring it up to 2.1 or later. The other day I had updated my clone to version 2.0 and built, but had not installed yet. So I installed it, then attempted to update to tip of trunk. That failed: [rosber15@aardwolf]$ fossil update trunk Autosync: http://fossil-scm.org/ Round-trips: 1 Artifacts sent: 0 received: 0 SQLITE_CONSTRAINT: abort at 14 in [INSERT INTO blob(rcvid,size,uuid,content)VALUES(0,-1,:uuid,NULL)]: CHECK constraint failed: blob fossil: SQL error: CHECK constraint failed: blob [rosber15@aardwolf]$ Before panicking, I did fossil rebuild and tried again, mostly because of what seemed like a database schema issue. Now fossil update trunk succeeds. So to move an existing project to the latest fossil after an SHA3-named artifact exists, it appears to be necessary to rebuild existing repos with version 2.0 or later so the database schema don't include a constraint that forbids SHA3 names. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Google Security Blog: Announcing the first SHA1 collision
On 2/23/2017 4:01 PM, Warren Young wrote: The PHC scheme would allow Fossil to migrate to something stronger in a backwards-compatible fashion: https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md That is, if the hash argument in the F, P, and Q cards is not 40 characters and it has a suitable prefix, it’s a new-style hash, else it’s a legacy SHA-1 hash. (I’ve previously suggested Modular Crypt Format for this, but PHC has some nice properties over MCF. See the link.) Tl;dr: Don't forget about human factors when considering a change. Should we decide to move to a new hash function, something like PHC is a decent approach for keeping track of hashes stored internally. But without some care, it is a usability nightmare, especially at the command line and in URLs (and wiki markup) where any "long enough" prefix of the hash serves to identify the target. One way of keeping that ease of use would be to match user input against a prefix of just the "hash string". Since PHC specifies that hashes are Base64 encoded, they are unlikely to collide with any existing SHA1 artifact ids, at least after a reasonable length. We would expect that most or all artifacts in a single repo would have the same $id and $parameters, so requiring the user to type them would be counter-productive. We should permit them, of course, to allow for explicitly naming a single artifact. Would we hash with salt? I don't know. If we did, then the salt would need to remain constant for any particular artifact for the lifetime of that artifact in that repo (and its clones). The salt could be as simple as the blob type suggested by Joerg [email today 9:37am], or it could include something more like a nonce. Using the blob type (perhaps with a short nonce appended) would get the advantages noted by Joerg when blobs are ingested (during push, pull, or rebuild); specifically blobs that smell like manifests but are not can be salted so that they are not parsed as manifests when ingested. Who gets to decide which hash should be used in a repo: Just Fossil's developers? The creator of a repo? The user of a repo? Regardless, I think we would agree that once a particular artifact is named in a manifest it cannot change hashes since that would require changing that manifest, which would change its hash, and so on. But perhaps the next checkin could use a different hash for some of its content, and to name its manifest. That would allow preservation of existing names for old artifacts alongside a new choice of hash functions for naming new artifacts. Warren [email today 2:54pm] is right that there are long lead times between any change we make and its dispersal into the wide universe of official distros and personal users. That tends to imply that if we think the threat potential of SHA1 collisions is a concern on the five year horizon, we need to implement whatever change we decide on soon so that it is in widespread use *before* the threat is real. All of that said, should we make a change? I'm not sure. Switching to a new hash has a non-trivial cost. Storing it in the PHC style (or inventing our own hash type metadata trick) seems like the way to mitigate the least expensive part of that cost. The rest of the cost is in the myriad implementation details and in designing for best backward compatibility to reduce friction for the user with 100s of personal repos. If we do make a change, I would resist the temptation to immediately rewrite the entire history to use the new hash. Certainly it would be possible to get a tree of all manifests and work through it replacing all SHA1 strings with the new hash. But that ignores all the other places that might have referred to a particular checkin by its SHA1 hash, most obviously wiki markup in wiki pages and technotes but also all those communicates about a work in progress. "Hey Joe, what happened in checkin [123456]?" in an email or chat log would now be impossible to relate back to history. Perhaps that could be mitigated by tagging each newly rewritten checkin with the SHA1 hash, possibly inventing a new kind of tag that can be matched by prefix for the purpose. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] fast-import crash (mark not declared)
On 2/16/2017 1:11 PM, Artur Shepilko wrote: This fix seems to allow the git fast-import to proceed past this ... until it finds another inconsistency, unrelated to the one above. This time it's with commit: https://www.sqlite.org/src/info/3f30f00a384d2358 Again, looking at the timeline https://www.sqlite.org/src/timeline?r=trunk=2010-09-28 There's a unusual timeline zig-zag on 2010-09-29, where a "future" commit (https://www.sqlite.org/src/info/655991ec8a781d67) is a parent to a "past" commit above. Apparently, there was some time skew which crept in. Same happened with the another subsequent "future" commit (https://www.sqlite.org/src/info/1ef0dc9328f47506, parent to "past" https://www.sqlite.org/src/info/f34dc54d46d05adf) . The timestamps for these "future" parent commits are supposed to be prior to timestamps of their children commits. Not sure what's a right way to fix the skewed timestamps, no handy command for this. Prehaps through "fossil sqlite3" direct surgery, but one needs to know how not to kill the patient in the process... Fossil hid some skeletons in the Sqlite's closet, Git just found some. Let's bring them to life :) I'd argue the problem here is with Git. Sure, we'd all love it if everyone kept their clocks in sync, but in the real world skew is simply going to happen. In the absence of a central server to provide the authoritative time stamp, a DVCS like both Fossil and Git has no real choice other than to trust the time provided by each local machine as authoritative enough to document each commit. If commits from each user of a project end up lined up in order on the timeline, that is just a happy side effect of people keeping their clocks synchronized. Having a parent committed after a child does look odd, but I think it has to be simply accepted as part of the record, warts and all, of the work on the project. I know that Git users like to be able to polish those warts off. Fossil doesn't care. And shouldn't care. The timestamp of each checkin is stored in the D card of the checkin's manifest, so it is not possible to edit it directly without changing the SHA1 hash of the checkin. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] UNMANAGE status
On 11/18/2016 12:46 PM, arnoldemu wrote: Does anyone else read it the first way? Either reading has the same end effect. After the command, the file is not managed by fossil, whether or not it had been at some point in the past. And a final question which is related: is there documentation which describes the possible responses and what they mean? If not would anyone mind if I wrote some documentation and submitted it to this list? More documentation is always welcome. There isn't a strong "house style", other than what can be gleaned from the existing documentation. For something like the list of status words, I can see arguments for either a central document that will land in the /www folder in the repository, or for extending the help text of the commands that emit the statements. Or both, where the command help is terse, and a more complete explanation that can cover the topic across the several commands can be in the /www folder. Either way, I believe Richard will be happiest with a signed contributor agreement from you on file [1]. The contributor notes all talk about source code. I don't know how much more relaxed he would be about pure documentation. [1] https://www.fossil-scm.org/index.html/doc/trunk/www/contribute.wiki -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Why we should NEVER use inetd/xinetd
Mr. User (if that is indeed your name): On 10/26/2016 4:30 PM, K. Fossil user wrote: In this mailing list we need to know everything about fossil and fossil related stuffs. - inetd/xinetd etc. that may be used in conjonction with Fossil (may be I am the only one who hear about a daemon (inetd) that was used with Fossil?) - security related (Fossil is a server sort of) Let me try to explain this a different way. The single fossil executable is several distinct things, and compatible with several distinct technologies. It also has additional features that can be enabled when building, which are not enabled by default. Fossil is: 1. A CLI program that as a DVCS uses a local repository to track changes. 2. A client for push/pull/sync with a remote repository 3. A CGI program usable from a big web server 4. A server, for both web and fossil sync, listening on port 80, 8080, or a configured port. Case 1 has no external security issues. You are at a command prompt. You can presumably do anything at all to your own files. Fossil won't actively help you destroy data any more than GCC does or your favorite IDE. Naturally it can be misused and could have bugs because we are only human. This case is exercised by the test suite that is run occasionally by various developers. Case 2 can be compiled to use SSL, otherwise it uses sockets in the clear. Login security and access controls are configured at the server end. Configuration can be subtle, but for simple open source projects it can be simple and largely just works. Cases 3 and 4 (and other subtly distinct variations that most often come up in some SSL configurations) are all on the server end. Case 3 is normal CGI. Overall security of the server is the responsibility of the world-facing web server. This might not be the "best" way to setup an externally accessible repository, but it is the easiest. Login security that controls access to the repository itself is handled by fossil, with a session cookie across transactions. If your web server already handles SSL, you can get SSL coverage of your repository essentially for free this way. Case 4 covers at least three distinct usage styles. It is how the "fossil ui" command is implemented, essentially by starting a server on localhost:8080 and launching a web browser to touch it. A long-running server can be easily set up for a single repository or a directory full or repositories with the "fossil server" command. You can also use (x)inetd or another launch and monitor daemon to defer launching fossil until the port is accessed. Under most conditions, if fossil happens to find itself running as root, it enters a chroot jail and drops as much privilege as it can. This mitigates most attacks that depend on getting something running as root to misbehave. Fossil doesn't examine the user's request until that is done. If inetd, xinetd, systemd, or something similar is used to launch fossil on demand, then that daemon is what is seen first by an attacker. The biggest concern is that a bug or incident might cause a denial of service by crashing that super-daemon. That is what happened with http://fossil-scm.org when you started flogging the inetd is evil horse recently. The daemon died. The machine didn't notice. Services not managed by that specific daemon remained alive. This is one of the problems that systemd is trying to solve: by being more aware of what is supposed to be running, systemd can notice losses and repair them. Many people think that is a good idea. Many people are not convinced. Inetd and its close relatives do less monitoring. But for a resource that is rarely used, having fossil launch when touched can be a better use of server resources than having fossil launched, listening, and paged in when touched. The bottom line is that fossil does not require the use of inetd, xinetd, systemd, a web server. But for systems where the administrator has made her own judgment of the balance of security, reliability, and other risk factors, the option is there. a) I have nothing to ask at this time, so I don't even need to learn how to [ask] Reasons you sound like a troll. 1. This statement right here. The questions you have asked have shown very little effort on your part. 2. Fake name. Not all trolls use aliases, sure. But I've seen far fewer outright trolls using obviously real identities. 3. Belligerence. We support fossil because it is useful to us. You approach us with a hostile attitude, then get worse when people engage and try to help. 4. The rest of this email which I'm not responding to in detail. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] windows compiling with MS VC
On 10/24/2016 2:12 PM, jungle Boogie wrote: On 24 October 2016 at 13:08, Warren Young <w...@etr-usa.com> wrote: ‘cl’ and related tools are not in the PATH after installing Visual Studio. If you look in the Start Menu folder for Visual Studio, you will find something like “VS2015 x86 Native Tools Command Prompt.” Running nmake under that should succeed, at least with this C99 fix in place. SUCCESS! I think MS gave up on putting the VS tool chain in the PATH by default when they started delivering both 32-bit and 64-bit toolchains. If you look in vcvarsall.bat, you'll see that the full environment it needs is more complicated than just the PATH, and looking in the nest of batch files now, it is more complicated than I recalled. As an embedded developer with many different compiler toolchains crossing my desk, I am very happy to see that from them. Back in the day, they used to insist on setting PATH, and then adding INCLUDE and LIB which often messed with other compilers, even other compilers targeting Windows let alone cross compilers. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] fast-export to git produces unimportable dump
Some aggressive pr0n-selling spammer is subscribed either directly or through an archive site. They are making a sequence of replies directly to the original poster, some just plain text, some including a link to follow, and some containing NSFW photographs. I've had pretty good luck with a black-list approach, where I've told my mail system to blacklist the domains the pr0n spam appears to come from. We'll see if this message catches some more fodder for my black-list. I don't have a good answer for what else to do about it. This is a particularly pernicious approach to address harvesting that does not lend itself well to discovery and mitigation. On 10/11/2016 1:22 PM, sky5w...@gmail.com wrote: Can confirm with gmail. Every post now has multiple spam replies. Fossil has been discovered! I suspect religiously reporting the offending email as spam to GMail will help in the long run. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] visual studio solution and project file for fossil
On 10/5/2016 3:27 PM, Richard Hipp wrote: On 10/5/16, Ross Berteig <r...@cheshireeng.com> wrote: Note that building for 64-bit needs something trickier than just following that recipe from a 64-bit VisualStudio prompt. Really? Because just typing "nmake /f makefile.msc" from a 64-bit VisualStudio prompt works fine for me on Windows10 with VS2012. I have VS2010 installed here. It is possible I was fooled by not having a clean enough workspace. Certainly, having zlib already built by a previous 32-bit compile wasn't helping. I tried to work around that by also setting FOSSIL_ENABLE_MINIZ=1 which did allow a clean compile and link. The resulting fossil.exe ran, at least fossil version -v worked. I did not run the test suite. But handing it to DEPENDS.EXE to see what DLLs it was really linked against showed a mix of 32-bit and 64-bit DLLs. That might be a red herring, and does seem odd to me given that the program does run at all. I certainly can try running the test suite over that fossil, and see what happens. I'll try that later tonight and report back. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] visual studio solution and project file for fossil
On 10/5/2016 11:30 AM, Richard Hipp wrote: On 10/5/16, arnoldemu <mem...@arnoldemu.freeserve.co.uk> wrote: I see that fossil can be built with a batch file "buildmsvc.bat" which uses the command-line visual studio compiler. It uses some kind of custom build where the headers which are needed are added to the files and output into a separate directory. I don't really understand fully how this works and is a guess from what I have seen so far. To build using msvc from the command-line: cd win nmake /f makefile.msc To get a debug build, just add DEBUG=1 to the nmake command. You might want that to be a clean build the first time so that you get everything built for debugging. You should be able to just use the resulting EXE and PDB files in Visual Studio. In a 32-bit VisualStudio command prompt where all the compiler tools are available: C:>cd win C:>nmake /f makefile.msc DEBUG=1 Note that building for 64-bit needs something trickier than just following that recipe from a 64-bit VisualStudio prompt. Fossil will build, but the resulting executable seems to be linked to a mix of 64-bit and 32-bit DLLs, and that can't possibly be the right answer. Personally, I've never built fossil other than 32-bit on Windows (and usually using GCC via MinGW) and I've never had any issues with it not being a 64-bit build. There are other configuration options you can choose in a similar way, see the start of Makefile.msc for the complete list. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Files named "AUX" on Windows
On 10/4/2016 12:40 PM, Andy Bradford wrote: Thus said Richard Hipp on Tue, 04 Oct 2016 12:15:58 -0400: Does anybody know of a reasonable work-around? What do other VCS do? Presumably CVS, SVN, Hg, Git, etc. have all Wsupported indows for a long time. Do they just return a sensible error? When we still used CVS around here, my recollection is that it simply failed spectacularly due to a lack of testing returns from system calls that "cannot fail". It wasn't the only problem we had with CVS. We switched to fossil for lots of reasons, but at the time all of the other choices seemed to be run by people with an attitude problem about Windows. This is one of those bugaboos that is mostly ignored by the tools, and that answer usually just works since eventually developers learn that they can't use those names. IMHO, using namespace tricks to create the files or folders with reserved names will only result in additional mysterious failures and pain for Windows users. No build systems or compilers will be using those tricks, and even deleting the files later becomes a problem for the user. The best action would be to make sure that the failure to write the file on a particular system gets a clear error message so the user knows who to blame, and doesn't blame fossil. A possible work-around would be to transform the name from a reserved name to a working (but unexpected) name. Fossil would need to have a setting to control that, and likely should provide configuration of what transformation is done. We already do something sort of like that for symbolic links, so there is that precedent. Just adding a tilde to the basename would be enough to allow the checkout. The project's build system or other automation would still be broken, of course. (A single setting could be added. If missing, fossil acts as it does now. If present, files that can't be opened are modified by appending the content of the setting to their basename. No idea what happens if you change that setting with a checkout open. It probably should be versionable. The mapping would need to apply to all of fossil's operations on that file or folder. This is beginning to sound like an iceberg-like feature. One setting implies 100s of lines of code.) Beyond that, the list of disallowed names is probably stable enough that a warning on checkin could be made. But I strongly suspect the usual response to that warning by a *nix user will be "#$*!@ Windows, I just want to check in and go home" and the bad names will lurk until the project gets ported. I vaguely recall hearing that there was a major open source project that had a folder named aux that was bit by this issue, and IIRC they ultimately resolved it by renaming the folder to something that worked on all platforms. I'm not recalling what project that was, though. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Files named "AUX" on Windows
On 10/4/2016 9:22 AM, Pierpaolo Bernardi wrote: On Tue, Oct 4, 2016 at 6:15 PM, Richard Hipp <d...@sqlite.org> wrote: See https://www.fossil-scm.org/aux-test/doc/trunk/aux.md Apparently if a Fossil repository contains a file whose basename is "aux", then an attempt to open or check-out that repo fails with an error. Only the basename needs to be "aux". The full name can be things like "src/aux.c" or "doc/aux.txt". Does anybody know of a reasonable work-around? According to this page, it looks like it can be done: https://blog.onetechnical.com/2006/11/16/forbidden-file-and-folder-names-on-windows/ The "official" story currently can be found here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx The bottom line remains the same, though. Due to a long chain of "reasonable at the time" backward compatibility decisions, there is a list of names that are recognized by the Windows API and cannot be file names. Some of those names were defined by DOS 1.0 and inherited from CP/M. So that is a *long* history. There are also ways to get around that. The blog post suggested a path prefixed by \\.\ would work. That might, but that prefix is documented for access to device drivers. There is also the \\?\ prefix, which can be used to get around the MAX_PATH length limit, and which sidesteps most parsing of the path name as a result. The best advice is to not use those reserved names for either files or folders in repositories that will be used on Windows. But in practice these are forbidden names in windows, the only reasonable path is to rename these files to something else. Although rare, it is possible for a suitably privileged user (likely through a badly thought out device driver) to create more such names. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] windows build assistance
On 9/22/2016 5:15 AM, Warren Young wrote: On Sep 21, 2016, at 2:06 PM, jungle Boogie <jungleboog...@gmail.com> wrote: I have installed mingw32-base and the installed version is 2013072200 and also mingw32-gcc-g++ with a version of 5.3.0-2 I don’t follow MinGW closely, but as I understand it, the mingw.org project is moribund. The 2013 release date suggests you’re using mingw.org, but the GCC 5.3.0 spec suggests MinGW-W64, a fork of MinGW that is actively maintained. The MinGW mailing list would disagree that it is dead, but it has been a long time since an update. Fortunately, fossil does not require bleeding edges of anything in either build tools or library support. If you do need a bleeding edge GCC on Windows, then the MinGW-W64 people can provide it. But be aware that there is a loud and large rift between the two projects, over a difference of interpretation of the license terms on MS API documentation. MinGW are very conservative, and refuse to include or support anything that can't be discovered from just the MSDN published reference manuals. The MinGW64 project is willing to consider the published Windows.h and related files to also be public API documentation despite the very threatening tone of the copyright notices in the files themselves. That difference leads to differing levels of support for new and interesting features of Windows. I installed MinGW and MSYS following the standard instructions a long time ago. I build (and test) fossil under MSYS's build of bash, and use it with no complaints on stock Windows ranging from XP to Win10 Pro across my organization's mixed bag of machines. Recently I started include OpenSSL support in my builds, and that came together with only a little hair-pulling and confusion. Building under MSYS bash allows ./configure to just work. I long ago copied mingw32-make.exe to make.exe on my path and all is just ducky. The test suites run just fine with a recent build of ActiveTcl also installed. I did have to use its package manager to add a JSON library (and I think one other, sha1 possibly?) to get all tests to run. I also occasionally have built from the Windows CMD prompt, using the command make -f win/Makefile.mingw which generally also works for me, except that the resulting fossil.exe does not include OpenSSL. I suspect it is possible to make it do so, but I have not worked out the right additional configuration to make it happen. The big advantage of a MingW32 build is that the result is a 32-bit binary that is linked against the same C runtime library DLL that ships natively in all versions of windows (at least since XP). Yes, that is officially not the recommended approach. But it is also the approach that until very recently MS themselves used for almost all bundled tools and utilities. While I run a 64-bit Windows on my desk, I have yet to be convinced that there is a need for fossil.exe to be a 64 bit build and have not even attempted to do that as an experiment. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 files.
On 9/12/2016 5:59 AM, Ron W wrote: On Sun, Sep 11, 2016 at 12:18 PM, Adam Jensen <han...@riseup.net <mailto:han...@riseup.net>> wrote: The phrase "ephemeral content" is a bit disconcerting. It suggests values and attitudes towards this data which will probably be reflected in the requirements, specification, and implementation of the software. In the use-case I have in mind, this data would be "immutable content" and should be considered precious. The goals would be to avoid accidental loss and/or corruption. It isn't a low-value, fleeting scratch-pad that would be thrown away on a regular basis. Unversioned means that if the file is committed again, the new contents will replace the current contents. If you only ever commit the (unversioned) file once, then it's contents will remain. In current fossil, the way to create a permanent and immutable file is to check it in. It can be thereafter (immutably) recovered by knowing its name and version, which can be summarized by its SHA1 hash. Syncing to multiple copies of the repository and taking backups improves the security of the data, but nothing can modify an artifact after it is checked in. I suppose, what you are looking for is a mechanism for preventing further commits to those files, therefore preventing the contents from being replaced. Perhaps marking the file as a "closed leaf" could be used as a means to achieve this immutability you are seeking. That would prevent further work on a branch containing that file, but only if that branch were the only branch holding the file. But then it would only be visible in the file system in a checkout of that specific branch. That would put a sizable crimp on the utility of such a file. That said, using a closed branch as a parking place for the data could work if combined with a build script that used "fossil artifact" to extract the immutable data files. If the data did need to mutate, you would reopen the branch and checkin the change. Then back on the the development branch you would edit that build script to request the new artifact ID. Clumsy, perhaps, but it would work today. There might be some value to being able to mark a file as "locked" somehow. Problem is that tags only relate to manifests, not to the individual files inside. I think it would require an extension to the manifest format (and the table schema too) to support such a per-file lock. But for some kinds of files, having a stumbling block that prevents casual changes might have sufficient value to be worth implementing in fossil itself. Without per-file tagging, you could have a build script that verifies the "immutable" files have not mutated, and then require that script be edited if a reason to update the immutable data is discovered. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Infinite loop on merge
On 9/7/2016 1:15 AM, Jan Nijtmans wrote:
Would this be enough reason to do a quick 1.35.1 release? Two
regressions are already found plaguing 1.35 for situations
which worked fine in 1.34. Branch "branch-1.35" is ready,
the only thing missing there is updating changelog.wiki.
I built and tested branch-1.35 with MinGW and MSYS on Windows 10 Pro
using the zlib from the tree with and without SSL support. Exactly two
test cases report failures: merge-utf-79-23 and merge-utf-79-32. Nearly
all released versions of fossil I've examined have a similar pair of
failed test cases.
So my testing does not block releasing 1.35.1.
I have no strong opinion about whether such an update is required, but
the most recent regression does seem like it causes real problems if
tripped over.
On the pair of failed tests: nearly all released versions of fossil have
failed a trial of the merge-utf-*-{23,32} cases. This is a family of
merge tests built using source files drawn from the fossil test suite
itself, which are hammered with random edits, merged, and validated. The
use of the random number generator fuzzes through a lot of cases.
Today's failure is the 79th fuzzing of utf.test. I strongly suspect that
this exposes an edge case in the merge logic when dealing with (likely)
broken UTF characters in one or more of the changes being merged.
Figuring out what is really going on there has been on my back burner
for a while now, I may have to give in to curiosity (despite what that
does to cats) and try to understand it one of these days.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
___
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] Fix for stash-next pointer (fix for the fix)
On 8/17/2016 1:01 PM, Warren Young wrote: It would indeed be nice if Fossil told you up front, as you said. The documentation for --force doesn’t explain this second usage, either. It only talks about “uncommitted changes,” which is not quite the same thing as stashed changes, at least to my mind. “Uncommitted” implies that committing them is the intent, whereas stashed changes may never be committed; if I was certain about keeping these changes or throwing them away, they wouldn’t be in the stash, they’d be committed or reverted. So, maybe you want to prepare a documentation patch rather than a functionality patch. The current (tip of trunk) help text for fossil close reads: $ fossil close --help Usage: fossil close ?OPTIONS? The opposite of "open". Close the current database connection. Require a -f or --force flag if there are unsaved changes in the current check-out or if there is non-empty stash. Options: --force|-f necessary to close a check out with uncommitted changes See also: open The text "or if there is a non-empty stash" was added by check-in [c6aedbd0] on 2013-06-22. I could see rewording the text for --force to be a little more succinct and not imply something that contradicts the paragraph above it. But all in all, this is pretty clear, IMHO. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] ambiguities and inconsistencies in --help
On 8/12/2016 11:04 AM, Kain Abel wrote: Dear developers, dear contributors, dear users, I've found some gaps and inconsistencies in the documentation on command line. Thank you for taking time to notice and point them out. The documentation always benefits from critical readers since its authors are also usually the developers and hence are often too close to the trees to see the forest. My starting point was: fossil init --help... There is no hint for DATETIME in the 'See also:' section. (A good format hint was found after a long time with "timeline --help".) The (command line) documentation lacks the information of the format and the supported subset of DATETIME or things like DATETIME can be a string and must be surrounded by ''/"" or not. Pretty much every command that takes a date and time has this shortcoming in the documentation. I'll take a crack at improving that. Until I get that done, the short answer is that it understands anything that SQLite's strftime() understands as a "time string". That means that many things that looks like a subset of an ISO8601 date and time string will work. Either the date or time can be omitted (but an omitted date will be 2001-01-01 which may not be obvious at a glance), and a timezone may be added. The keyword "now" also works, as does a fractional Julian day number. See https://www.sqlite.org/lang_datefunc.html for the full story under the heading "Time Strings". But note that as called from fossil, none of the documented time modifiers are possible. For fun, you can try feeding things to the test-date-format command: $ fossil test-date-format now now -> 2016-08-12T21:51:51.775 $ fossil test-date-format "2016-08-01 09:00:00-07:00" # PDT 2016-08-01 09:00:00-07:00 -> 2016-08-01T16:00:00.000 $ fossil test-date-format "2016-08-01 09:00:00Z"# Explicit UTC 2016-08-01 09:00:00Z -> 2016-08-01T09:00:00.000 Other to briefly documented formats are: TYPE and DATE. It appears likely all references to a DATE are really a DATETIME. I'll review that. I'll fix up the date and time documentation, then consider the other nits you've raised. ... Supposed inconsistencies: (in the output of --help or a closer look at 'fossil test-all-help') armend|branch|commit: the usage of DATE vs DATETIME? the switch in armend: --date vs --date-override (used in init|commit|branch|tag) Missing switch documentation -n for --dry-run in the help of command purge. Missing switch documentation -v for --verbose in the help of command clone. Missing (hidden) alias 'list' for command 'ls'. If 'ls' used as a subcommand, then is always/mostly? the alias 'list' present. (fossil list vs. fossil stash list) Missing desciption of TYPE's in whatis. Undocumented and missing type 'g' in timeline. It is possible to introduce also unified shortcuts for the switches --date-override|-OD (in branch, commit, tag) --user-override|-OU (in branch, commit, tag, init|new) ? They are long and ugly to type. ;) I know I'm annoying: Other wishes of commonly/often used switches (*x systems) -h as shortcut for --help -u as shortcut for --unified in diff -b as shortcut for --brief in diff (was also used in dbstat, extras, finfo) and also the silent switch -q as 2nd aka for compatibility with GNU/diff --brief? Thanks for your time and work! Best regards, Kain ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] change sync URL
On 8/10/2016 11:43 AM, jungle Boogie wrote: If I have a repo syncing to example.com and I want to change it to sync locally on my network, what's the best method to update the sync url? Set the url:fossil remote-url http://new-url-here.local/ Turn off sync: fossil remote-url off -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] tags manifest
On 8/6/2016 12:02 PM, Jan Danielsson wrote: On 05/08/16 02:51, Ross Berteig wrote: Many thanks; this saved me a lot of time, as a non-native tcl speaker. And as such, I also would like someone to quickly look over the additions I've made. It seems to work, but I have a feeling I have have reinvented the wheel. Your additions look fine to me, but I too am a non-native Tcl speaker. I added more tests in the same file, but given the "set-" prefix I assume it would have been better to split the manifest.tags content tests to a separate test. On the other hand, there aren't many tests overall so it doesn't hurt having them all in a single file for now. This file seems sensible to me. My logic is that the feature here is the effect of the "manifest" setting. It originally just controlled whether the If anything, I should add a few tests related to the specific content of the other two kinds of manifest files that are all controlled by the single manifest setting. I think I'll lean on your new file_contains function to do that for manifest. The manifest.uuid is easy to compare to the output of fossil info. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] tags manifest
On 8/4/2016 2:33 PM, Ross Berteig wrote: I just built it and ran the existing test suite over it on Windows. It passes all existing tests. I didn't spot any test cases for the new feature I just created test cases for fossil set manifest that verify that the files manifest, manifest.uuid, and manifest.tags appear and disappear as the setting is changed. I did not verify that any of the files have the right content. I'm not sure offhand how our test coverage looks for all settings. Writing tests that cover every setting is probably a worthy goal for a long term and low priority project for someone who wants to visit all the nooks and crannies in the fossil source kit. On the assumption that there will be more tests related to settings, I named the new file test/set-manifest.test so there is an obvious naming pattern to follow for tests of other features primarily exposed through settings. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] tags manifest
On 8/3/2016 9:24 AM, Jan Danielsson wrote: For those who are afraid of new features messing with your current setup: The jan-manifest-tags branch is explicitly designed to not interfere with your current setup. You need to take action for a change to occur. If you use "set manifest on" or "set manifest off" it will work exactly like it always has. I.e. if you don't care about this feature, you - as an end user - will not notice it's there (apart an updates settings field and help text). I just built it and ran the existing test suite over it on Windows. It passes all existing tests. I didn't spot any test cases for the new feature. While I don't see that as blocking a merge to trunk (it didn't break any existing tested feature) I do think that we should write some test cases for the new treatment of the manifest setting, as well as the new tag manifest before the next "release" of fossil after this feature is merged. I'm not sure offhand how our test coverage looks for all settings. Writing tests that cover every setting is probably a worthy goal for a long term and low priority project for someone who wants to visit all the nooks and crannies in the fossil source kit. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Release 1.35 checksums?
On 7/1/2016 10:35 AM, Warren Young wrote: On Jul 1, 2016, at 11:13 AM, Todd C. Olson <t...@cornell.edu> wrote: Then why does fossil-scm.org offer checksums at all? Better question: why does any download site offer checksums? One answer is mirrors. If a download is widely mirrored, then one might have reason for concern that a third-party provided mirror might be serving up modified content. Having the official site publish one or more checksums is a cheap way of providing some assurance that hasn't happened. A cryptographic signature would be stronger, but enough harder for end users to verify that it would not be checked at all. It did happen to a number of iOS developers in China recently. They were of the habit of getting developer tools from a mirror site that was far closer to them (by bandwidth and download time measures) than the official Apple sites. The tools they got included a modified toolchain that produced iOS app with backdoor access. That also passed all Apple review stages since they were linked against "official" libraries. That said, fossil doesn't provide an automated pool of mirrors hosted at third party providers so this would be less of a concern. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 comment editor transforms LF into CRLF
On 6/17/2016 5:33 PM, Scott Robison wrote: On Fri, Jun 17, 2016 at 6:04 PM, Warren Young <w...@etr-usa.com <mailto:w...@etr-usa.com>> wrote: For any blob data that Fossil considers “text,” why not strip all CRs on ingest, then based on either a setting or platform check inject CRs as necessary when expelling a copy from the DB? Then users checking out on Windows will see the CRLFs they want, and Fossil doesn’t have to deal with CRs appearing and disappearing as different users on different platforms edit the same files? Ah. I was just thinking for the text that fossil itself injects, not something that would impact all blobs. I wouldn't be opposed to that myself, but I can appreciate why it isn't a desirable thing for fossil to do. IMHO, I think that one of fossil's strong points is that it is remarkably unaware of text vs. binary issues. Storing all files byte for byte as they are in the file system is a reflection of that. So is being agnostic about line ending when implementing text presentation features such as diff. For text that is the property of fossil itself, such as checkin comments, it is completely fair and reasonable for it to pick a preferred line ending and convert to it from entry and from it on display. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Weird cross-contamination between two fossil repositories (and not even talking to server!)
On 5/27/2016 3:58 PM, John P. Rouillard wrote: Hi Richard: Richard Hipp writes: Just to be clear, I consider anything involving shunning to be out-of-the-ordinary. Perfectly reasonable. On that note, does anybody have code for tcl hooks that can be used to reject artifacts that have text that matches a particular pattern IMHO, that is capability is outside the core mission of fossil. One of the great selling points of fossil to new users is the low ceremony of fossil. One executable. A repo is a single file, that can even safely reside in the same folder as your checkout. And very little policy is enforced by fossil directly. Aside, of course, from the big one: fossil preserves everything, and that history is immutable. That said, there is a hook mechanism that can be used to check preconditions before executing a command. It might require some cleverness to use it for this purpose, however. Hooks exist if fossil is compiled with the option, are written in TH1, can configured to make Tcl available to TH1, and are not extensively documented. One of the hooks is "command_hook" which is invoked for every fossil command. That name can raise an error (or call break or continue) to prevent the fossil command from executing. Since the hook is called early, it knows the command name, its arguments, its flags, and not a lot else. Hence the need for cleverness since you would want to learn what files are going to be committed. This hook has to run at the client, and before the commit is performed. So that won't prevent a user from bypassing it, or a misconfigured repostory from failing to call it, or if depending on Tcl, I'm sure there are more failure modes since Tcl is (usually, depending on configuration of fossil) loaded from the system at run time. If you really wanted to commit a file that matched that pattern, you added a string like: BYPASSPASSWORD to the commit message and the check would be bypassed. The fossil -no-th-hooks option will skip all hooks for that command. Depending on what else you do in a hook, that might be more than you wanted. Is there some similar way to inspect the transferred artifacts and file contents and roll back the commit? Nope. And there can't be. Nothing is transferred until well after the whole collection of artifacts that make up the commit have been created and safely stowed in the local repository. There is no "roll back" from that. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Rejected JSON tests
On 5/27/2016 4:39 AM, Kain Abel wrote: Dear devs, dear users, the script tester.tcl don't like the JSON support?. lm@um:/tmp$ tclsh /tmp/test/tester.tcl /tmp/fossil -quiet -prot can't find package json while executing "package require json" (file "/tmp/test/json.test" line 38) invoked from within The issue here is that you don't have the json package installed in your copy of Tcl with which you are running the test harness. There is a comment in json.test that has the reminder of which json library I used. Specifically, I used the one from tcllib, as packaged and delivered by ActiveTcl's teacup utility. https://www.fossil-scm.org/index.html/artifact/65f8333164e4?txt=1=33-38 On linux, you'll have to find your own way to get the library, IIRC I was able to tease it out of apt-get, but I don't recall what its name was. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] No progress on "fossil cp"
On 5/16/2016 9:53 AM, Warren Young wrote: On May 14, 2016, at 4:35 AM, Stephan Beal <sgb...@googlemail.com> wrote: But in svn, now that i think about it, cp is, in practice, only used for branching. ... If the SCM doesn’t remember that y.cpp was cloned from x.cpp Actually, a copy command would sometimes be nice when refactoring an over-large module into several smaller modules, in that it would preserve more history in a place where it might be sought later. For extra credit, one might imagine an analysis something like the existing annotate/blame features that allows a file that is fragmented into several files to preserve only the history pertinent to the bits that move to each fragment in that fragment. I have no clue what the UI for such a feature should look like, however. Personally, I usually just treat such copies (or fragments after a refactor) as brand new, and get on with life. Tracking everything sounds nice on paper, but I'm not sure it is actually worth the required effort. That would require a backwards-incompatible change to the manifest format Unless some clever trick can be invented that will let older versions of fossil simply see such files as newly added at the time of the copy while letting a new version also track the history across that event. I'm not steeped enough in the manifest details to know what is possible myself, however. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Quirk with GUI vs CLI timelines of technotes.
While reviewing the technoteattachcli branch, I noticed this anomoly. Compare https://www.fossil-scm.org/index.html/timeline?n=50=e=0 to fossil timeline -t The list of (abbreviated) SHA-1 hashes is different. One is showing the internal technote artifact, and the other the generated technnote name. I'd argue the two displays should agree. I'm not sure at the moment which display of the timeline is "correct". -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Some more default settings for a UI user
On 4/23/2016 5:06 PM, Marko Käning wrote: On 24 Apr 2016, at 01:45 , John P. Rouillard <rouilj+fos...@cs.umb.edu> wrote: However once you had that info in the database, IIRC you can use th1 to find out who the current user is. Then you can make sql calls into the database. So I think in theory you could change/create a user schema that holds personalized settings and use th1 to customize the menu item. I see. Well, I’ve reconfigured the repo’s header now to my linking. Having just skimmed this thread, I think we're all missing an elephant in the room here. A very common usage model for fossil is for each dev to have their own clone. That clone has (by nature) complete copies of the tickets and timeline, assuming that autosync is on, or that sync has been happening regularly. (I don't think that ticket updates in a local copy trigger autosync. I vaguely recall some discussion about that in the past.) But skins are not autosync'ed. You get a copy of some skin on clone, but without some effort by an authorized user of the main repo, no changes made to a skin in a clone will propagate back. So if you have personal preferences for timeline defaults, repo home page, cosmetic features in the CSS, or similar, you can just change those in your clone and use "fossil ui" to play with the repo with those defaults. If it is important that multiple users of the web UI on a single server see different or personalized settings, that would be trickier. But a way to do that would be to serve different clones to each user, and use a cron job to keep them all synced. Probably not worth the effort unless the value added to the user's convenience is significant. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 all ignore and case insensitive paths
We just happened to notice today that the list of repositories maintained for the use of "fossil all" is (naturally) stored with exactly the case that was used when each repository was mentioned to fossil. Several folder names happened to be stored with different case than they actually have in the file system. All was well with most commands since Windows is a case-preserving but case-insensitive place. But c:...> fossil all ignore some.fossil didn't actually ignore it when done from that folder. Adding --dry-run and comparing to the output of "fossil all list" revealed the different case, and --dry-run shows that the problem is that SQLite's GLOB operator is case sensitive: DELETE FROM global_config WHERE name GLOB 'repo:K:/Some/MixedCase/PATH/some.fossil' Should fossil all ignore respect the case-sensitive setting (or the mounted file system's capabilities, or the OS defaults, or) and try to match names insensitively when appropriate for the context? Or is that actually as large a can or worms as it sounds as I type this question? It seems like adding "COLLATE NOCASE" after the WHERE clause might do the trick. But the difficulty is likely deciding when to add it. And then hoping no one needed proper handling of cases for anything other than 7-bit ASCII letters. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature implemented or suggestion for stash
On 4/14/2016 11:10 AM, Stephan Beal wrote: On Thu, Apr 14, 2016 at 7:00 PM, Warren Young <w...@etr-usa.com <mailto:w...@etr-usa.com>> wrote: On Apr 12, 2016, at 11:30 PM, Stephan Beal <sgb...@googlemail.com <mailto:sgb...@googlemail.com>> wrote: > i haven't ever bisected. Wow… I don’t bisect every day, but when I do bisect, I bisect with Fossil. :) The ability to bisect is one of the strongest arguments in favor of version control. I've needed it in the past, but as luck had it only on projects from before I knew about fossil, and I suspect before fossil really existed. CVS was fine for keeping a change log and record of the past from which with great luck and careful usage one *might* be able to return to a past build. Bisect was not something that would have been easily done with it. Since I've been using fossil, luck has mostly kept me from needing to search for obscure bugs that were latent until noticed. But from watching the list and noticing the ease with which others have used it for that purpose, it was clearly not only a compelling argument in favor of version control, but also a compelling reason to never check in anything to trunk that breaks the build. i admit that it's a fantastic capability, i've just never needed to use it. (Contrast with "fossil clean" - i have Opinions about anyone other than myself cleaning up my source trees, and simply _won't_ use that feature.) I'm 100% with Stephan on this one. On those rare occasions where I've wanted the effect of fossil clean, I've opened a fresh working directory instead. <their internal implementation and installed tools as well as to the user's source and object files. The biggest offenders are the customized junk provided by SOC vendors without which it is often impossible to build their sample code or even cross compile for their platform without a whole lot of reverse engineering of their tool chain.>> -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Getting time of last repository change
On 4/11/2016 8:17 AM, Stephan Beal wrote:
On Mon, Apr 11, 2016 at 5:06 PM, Jan Danielsson
<jan.m.daniels...@gmail.com <mailto:jan.m.daniels...@gmail.com>> wrote:
The most obvious method would be to do roughly what the timeline
does
and find the latest modification on the timeline, but this wouldn't work
(since it would miss modifications from older checkins (say a user on a
secondary site checks in an old experimental branch)).
That would still retain the current time for timeline purpose, making it
the newest (assuming there's not a clock skew or similar, in which case
all bets are off).
Ach... i just set up this new PC yesterday and don't have any source
repos (nor a copy of fossil) on it, so i can't try this out right now.
Checkins store their times in their manifests, but the timeline is the
only place the change times are stored in an immediately useful form.
IIRC the field is mtime, so something like:
echo "select max(mtime) from timeline;" | fossil sqlite
Is there a timestamp for when artifacts where locally added to the
repository? (I'm not overly concerned with configuration changes and
such; it's detecting checkins, tickets and other artifact changes that's
important).
There is the pseudo-revision named "tip" that is the most recent checkin
on any branch. It can be used along with the fossil whatis command to
learn tip's UUID and (probably) timestamp:
C:\Users\Ross\Documents\tmp\fossil4>fossil whatis tip
name: tip
artifact: 023601fb148541f4883713cf51615f26d99fe3e4
size: 51123 bytes
tags: andygoth-quote-apostrophe
type: Check-in by andygoth on 2016-04-09 19:14:09
comment:Merge trunk.
Or just limit the timeline output to one result:
C:\Users\Ross\Documents\tmp\fossil4>fossil timeline -n 1
=== 2016-04-09 ===
19:14:09 [023601fb14] *MERGE* Merge trunk. (user: andygoth tags:
andygoth-quote-apostrophe)
--- entry limit (1) reached ---
The latter can be done with json support for easier parsing, if you have
json enable in your build:
C:\Users\Ross\Documents\tmp\fossil4>fossil json timeline checkin -n 1
{
"fossil":"9c65b5432e4aeecf3556e5550c338ce93fd861cc",
"timestamp":1460399740,
"command":"timeline/checkin",
"procTimeUs":0,
"procTimeMs":0,
"payload":{
"limit":1,
"timeline":[{
"type":"checkin",
"uuid":"023601fb148541f4883713cf51615f26d99fe3e4",
"isLeaf":true,
"timestamp":1460254449,
"user":"andygoth",
"comment":"Merge trunk.",
"parents":[
"cc8e56f19ec618eed344acc062fd56667f78ae4d",
"96dec24eaf2e7a604aee71faf2deb2421db4e035"
],
"tags":["andygoth-quote-apostrophe"]
}]
}
}
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
___
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 update --latest not working
On 4/7/2016 5:02 AM, Richard Hipp wrote: On 4/7/16, John Regehr <reg...@cs.utah.edu> wrote: Is that expected that I will be silently moved between branches? Normally Fossil does not move between branches. Except, if you use the --latest option, it will move to the most latest descendent of the current check-out, regardless of the branch If you want to move to the latest trunk check-in, then the command to use is "fossil update trunk". That answers a nagging question I'd had: What is the difference between "fossil update --latest" and "fossil update tip"? Answer: "tip" is the very last checkin to any branch, while "--latest" is the very last checkin descending from "current". So now my question is what can we do to the wording of the help for update that makes the actual meaning of --latest clearer? It currently says: Usage: %fossil update ?OPTIONS? ?VERSION? ?FILES...? The VERSION argument can be a specific version or tag or branch name. If the VERSION argument is omitted, then the leaf of the subtree that begins at the current version is used, if there is only a single leaf. VERSION can also be "current" to select the leaf of the current version or "latest" to select the most recent check-in. Options: --latest acceptable in place of VERSION, update to latest version One thing that should be at least hinted at here is that using anything other than "fossil update" or "fossil update current" (which are exact synonyms) *can* move you to a different branch, and unless you are deliberately attempting to change to a different branch that move is likely to be surprising. It should probably also say that "--latest" and "latest" are the same thing. As it is worded now, the two ways of describing it seem to hint at a difference that isn't there. I'll take a crack at rewriting that "soon", but if anyone else has ideas I'm all ears... -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] typos
On 4/4/2016 11:33 AM, Ross Berteig wrote: On 4/2/2016 3:40 AM, Svyatoslav Mishyn wrote: But why that commit [b6b50b12] is marked as *FORK* in timeline.rss; and as *BRANCH* in `fossil timeline`; while here https://www.fossil-scm.org/index.html/info/b6b50b1244796110 looks like usual commit.. Oooh, that's weird. Possibly not all that weird after all. At a quick glance at the current batch, it looks like it is calling any node a *FORK* if there is more than one descendent. Bingo. The source code here: https://www.fossil-scm.org/index.html/artifact/09319f9b1c1b31cf4c6340f6ce36c0ba0d1f8fb0?txt=1=186-192 clearly shows that it calls anything with more than one parent a MERGE and more than one child a FORK. It even has MERGE/FORK if both cases are true. Going out on a limb here, this was by design. A refinement would be to distinguish the case of a branch point from a fork, with the additional complication of a node that might be both, or even both and a merge point. (The same decision is made in the fossil rss command as well.) So that raises the question of complexity versus clarity. From the definitions published in the documentation here: https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki a branch point is a special case of a fork, even if it is strongly intended to be the only kind of fork that normally occurs. I wouldn't oppose a change to the RSS feed however, if there's an easy way to do the right thing. I just don't have that fix at my fingertips. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] typos
On 4/2/2016 3:40 AM, Svyatoslav Mishyn wrote: (Fri, 01 Apr 17:50) Ross Berteig: Even better, Joe has already done that to trunk. But why that commit [b6b50b12] is marked as *FORK* in timeline.rss; and as *BRANCH* in `fossil timeline`; while here https://www.fossil-scm.org/index.html/info/b6b50b1244796110 looks like usual commit.. Oooh, that's weird. Narrowing to just checkins on trunk, we can see several more cases that have done the same thing. Someone more familiar with the RSS generator should take a look, it doesn't look right. https://www.fossil-scm.org/index.html/timeline.rss?y=ci=trunk At a quick glance at the current batch, it looks like it is calling any node a *FORK* if there is more than one descendent. But in all the cases covered right now, these are nodes that have branches and are not properly a *FORK* as we normally use the term in fossil. (And after quickly rereading https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki I think the documentation does agree with that statement.) It would be better to label it as "Branch Point" or possibly just "Branch" for brevity in the RSS feed. Unless it really *is* a fork, of course. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] typos
On 4/1/2016 7:14 PM, Warren Young wrote: On Apr 1, 2016, at 7:13 PM, Warren Young <w...@etr-usa.com> wrote: On Apr 1, 2016, at 6:50 PM, Ross Berteig <r...@cheshireeng.com> wrote: may I recommend just reading /test-all-help cover to cover once in a while? Okay. Back in a few… A few hours, that is. :) Aaaand I’m back. :) I found that page so helpful that I added a link to it from my Fossil skin’s header. Recipe: html "RefMan\n” Maybe this should be a standard feature? I've done the same thing, or at least dropped the similar link into a prominent place, in several project repos of mine. If it were to become a standard feature, I think it likely should be split into two major sections. One for the web face, and one for the CLI. Their audiences are, I think, different kinds of users. That said, for the task I foolishly just dove into, having them all in one document is handy for proofreading and verifying consistency. I’m not wild about the name RefMan. I just thought “Help” implied something a bit more like a user manual than what this link provides, which is basically a reference manual. Yeah, this is a pretty bare reference to all commands and web pages. A lot is left unsaid, or left to be inferred from the web of see also and casual name dropping. Including some additional overview topics in the compiled-in help would go a long way to softening some of the sharp edges. It would be nice if there was a mode for the code that generates this page to cause it to compress out the redundancy. That is, instead of separate annotate, blame and praise sections, I’d prefer a variant of this page that just listed the three aliases together, with a single copy of the explanatory text. The implementation of /test-all-help is probably only seven lines of code, and simply spits out a section for each entry in the large array built by mkindex. The order in the output is exactly the order in the internal array. The new test-all-help command is very similar, except I added some options to pick and choose chunks in ways that made sense to me but likely aren't the best choice. The fact that some commands are synonyms is almost entirely discarded by mkindex, and would be difficult for the help system to notice right now. (In effect, it would have to scan a table sorted by command name to find commands that happen to have the same function pointer stored.) But I'm sure if we had a mandate to make the help system more useful from the web that some combination of improvements to mkindex, the supporting data structures, and the page implementation could happen. But, it’s quite useful as-is. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] typos
On 4/1/2016 6:13 PM, Warren Young wrote: On Apr 1, 2016, at 6:50 PM, Ross Berteig <r...@cheshireeng.com> wrote: ... * "mtime" or "modification time”? That one’s different, with a much stronger claim: man 2 stat. That is, it is a ~45-year old term of art, not a neologism. Well, yes. That one isn't a neologism, it is a symbol retained from an era when the linker used to link the original Unix kernel could only handle six character names. And since even really really early Unix file systems kept distinct fields for access, modification, and creation times, it likely is ~45 years old. I likely first encountered it on a VAX 11/780 that booted a BSD Unix in the early 80s, but that was still quite a while ago. You can argue that fossil shouldn’t be exposing Unix plumbing here, but you can’t argue that mtime is not well-understood by those versed in the art of Unix. While it is true that any seasoned Unix user (and likely even newcomers who grew up on linux and may not even know why their OS has a funny name) will recognize it, it is very much a platform-specific bit of jargon. It would likely be unfamiliar to anyone having only Windows API experience, for instance. I think in most places that it is used, a longer phrase would fit as well in context, and would be clear to both Unix and Windows folks alike. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] typos
On 4/1/2016 8:08 AM, jungle Boogie wrote: > I bet if you make some patches, people will apply them. Even better, Joe has already done that to trunk. Which I'm glad I checked before I decided to dive in and just do it. But that inspired me to take /test-all-help and run it through a spell check. (Notably documented to be the reason that page exists.) As an aside, may I recommend just reading /test-all-help cover to cover once in a while? I learned a few things on this pass through it that I didn't know were there... To make my spell check easier, I added a new fossil test-all-help command, which dumps all the help text to stdout. It is otherwise essentially the same as the /test-all-help page. I found and fixed a few more simple typos in the help text. I reworded some help text for grammar and clarity. I would like to make some nomenclature consistent across the help text, page content, and CLI output. I've changed a couple of spots, but stopped short of sweeping the entire source kit for all the others. I notice that these appear in the help text and in page content (and likely CLI output) with inconsistent spelling. First: "technote", "tech note", "tech-note", "Tech-Note", and more variations. I propose that we call them "technical notes" in running text (with initial cap and/or plural as appropriate to context), and pick one abbreviation and stick to it where a shorter form is preferred. I like "technote" for that case, but I'm an engineer (and magician) and as such not at all a "normal" user. It looks like DRH intended to use "tech-note", but wasn't perfectly consistent. I'm happy with either, as long as we are consistent. Note: we should look for any dangling use of "event" too, I just noticed that fossil dbstat says "events" not "tech-notes". And the perennial: "UID", "checkin ID", and lots of similar terms. As far as I know, we never really have settled on the right single word to adopt for what we mean here. I don't have an answer, just noticing again that there's a lot of terms used in the help text. We aren't consistent about what help text begins with a capital letter and contains whole sentences. I've touched a number of cases in option lists where some descriptions start with a lower case letter. I haven't swept for all of them, but having a mix in the same list is jarring. On a wider content and style theme, I've noticed a few cases where global options (options parsed out of the fossil command line by main() before any subcommand is parsed) are called out explicitly in the help for a subcommand, but not used in a special way. That was part of what caused me to write the documentation of environment variables and global options. But I'm wondering if we shouldn't add a "fossil" subcommand that is there solely as a placeholder for documentation of things like --args, -R, as well as the general usage line for fossil itself. Either that or the help text for "fossil help" could include it, or even the usage text produced by "fossil" with no command at all. I'm not sure which is best, or necessarily that we should restrict it to just one of those places. It is hard to imagine the mind set of the new user, after all. Finally, and down at the "can it be worth even thinking about this" priority, my inner grammar nag is questioning these random non-standard English terms. On the one hand, using a neologism as a jargon term with an exact meaning in this context is probably good. On the other, where plain English would do just as well, it probably should be preferred. * "webpage" or "web page"? * "filename" or "file name"? * "timestamp" or "time stamp"? * "mtime" or "modification time"? -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Last call for "testerCleanup" branch review...
On 3/7/2016 12:39 PM, Joe Mistachkin wrote: Ross Berteig wrote: I don't think that is needed any more? $ fossil open ../fossil.fossil $ ./configure --with-miniz --with-openssl=none $ make test" In an open checkout: cannot initialize a new repository here. while executing "error "In an open checkout: cannot initialize a new repository here."" I missed a detail in that run. Turned out that I was building from tip of trunk, not the testerCleanup branch. But the same issue applies. Currently, this behavior can be disabled by setting the environment variable "FOSSIL_TEST_DANGEROUS_IGNORE_OPEN_CHECKOUT" to "YES_DO_IT". I'm still not 100% sure we want to disable this checking by default, although I might be convinced otherwise. I ran "make test" with that environment variable set, with the above recipe tweaked by inserting "fossil update testerCleanup" before running configure. I checked "fossil timeline" and "fossil changes" before and after to make sure that no case actually modified the repository. After the run, "fossil timeline", "fossil changes", and the filesystem time stamps on the repository and local _FOSSIL_ databases all agree that no test case wrote to the repository or to the checkout. I can confirm that without setting the environment, "make test" in an external build directory works as expected. I think that if the Makefile is going provide a "test" target, then it should be usable in the obvious case of "./configure; make; make test". Otherwise, something (configure?) should be enforcing the rule that building be out of tree. Building out of tree is certainly sensible, and anyone building more than one configuration (especially anyone cross compiling) will want to do that. But it is unneeded friction for someone who just wants a copy of fossil with a tweaked configuration, and they should still be able to run the test harness for confidence if desired. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Last call for "testerCleanup" branch review...
On 3/5/2016 11:27 AM, Joe Mistachkin wrote: I think this branch is ready and I'm planning on merging these changes to trunk on Tuesday, March 8th, 2016. Please feel free to raise objections. I would still like "make test" to work, and we are 99% of the way there I think. The easy part is tweaking main.mk. But repo_init is still being paranoid about [pwd] when tester.tcl is invoked being within a checkout. I don't think that is needed any more? $ fossil open ../fossil.fossil $ ./configure --with-miniz --with-openssl=none $ make test" In an open checkout: cannot initialize a new repository here. while executing "error "In an open checkout: cannot initialize a new repository here."" (procedure "repo_init" line 5) invoked from within "repo_init" (file "C:/Users/Ross/Documents/tmp/tf/test/amend.test" line 52) I updated main.mk (via makemake.tcl) and checked that in. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Last call for "testerCleanup" branch review...
On 3/5/2016 4:48 PM, to...@acm.org wrote: Can someone shed some light (or point me to a link) as to what this new feature is supposed to do? (I must have missed any prior discussion on this.) This branch has been about improving the test harness that we use to test fossil. That test harness is found in the fossil source repository in the test/ folder, and consists of test/tester.tcl and test/*.test. The changes here move the temporary working folders used by each test case out of the current directory into a suitable place for temporary files, and completely delete them when the tests are complete. A new option, -keep, is also provided to the test harness that causes it not to delete the working files, allowing them to be inspected. This is particularly useful when debugging test cases. One of the goals here is to permit "make test" to just work and provide a decent confidence level that most fossil features are touched. We haven't reached that goal completely, but this is a strong step along the way. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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-dev] Call for review / testing...
On 3/4/2016 4:18 PM, Joe Mistachkin wrote: Yes, using the default (/tmp on POSIX) should be fine, because all files are created within sub-directories of it anyhow (home_ and repo_). Also, I've just added the -keep option (on the branch). Thanks, that will be helpful. Looks like I will be using it to debug an issue in the fossil json test cases "real soon now". -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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-dev] Call for review / testing...
On 3/3/2016 9:21 PM, Andy Bradford wrote: Thus said "Joe Mistachkin" on Thu, 03 Mar 2016 17:31:18 -0800: The way trunk works is probably not the best model. I agree. On Windows it works fine as long as the not in checkout restriction is enforced. But I do like the idea of lifting that restriction and allowing "./configure; make; make test" to simply work without modifying either the user's global fossil state or fossil's own repository. I think these changes are getting really close to that point, and once confirmed, the loud warnings in main.mk should also be removed. > I did not mean to imply that the way it works in trunk is the best model, and in fact, I admitted as much in a previous email. Having to take extra measures to avoid clutter was certainly a ``thing'' to do, but not necessarily onerous. I mean that having the clutter be created in [pwd] is not a bad option. I certainly agree that the way tempPath is generated in trunk is wrong. It should have been using at least [pwd] and the existing mechanism of checking for the existence of an open repository would have prevented testing therein. At any rate, as long as nobody is relying on the trunk mechanism of writing things in [pwd] for their testing of Fossil, ... The JSON test cases create files on the fly in their [pwd] at run time. I'm sure many of the others do too. There are a few (the three way merge tests leap to mind, there's a bug in there that disappeared when utf8.test got edited that really should be investigated) that use files from the folder where tester.tcl is located as their source material. An argument for clutter in [pwd] when [pwd] is outside of the tree is that makes it easy to debug the test framework itself. If we know where the clutter lands, we can run a failing test and poke interactively at the clutter it left behind to understand why it fails. I did this extensively while putting together the JSON tests. For that use case, it isn't mandatory that the test clutter land in [pwd], just that it be possible to have it not get cleaned up, and land in a known place. Another runtime option to tester.tcl (-keep?) would be sufficient. I like the default behavior being to clean everything up. ... this change simply means that now people will have to explicitly set FOSSIL_TEST_TEMP as yet another step to get testing working. E.g. mkdir /tmp/test && cd /tmp/test && test vs mkdir /tmp/test && cd /tmp/test && env FOSSIL_TEST_TEMP=$(pwd) test Or if /tmp floats your boat, then do nothing at all and let tester.tcl use it by default. Set TEMP (first found of FOSSIL_TEST_TEMP, FOSSIL_TEMP, TEMP, or TMP with each checked as all caps, all lowercase, and initial caps) to force it to land somewhere known. Also use -keep (which certainly should cause it to print the location of the clutter) to keep the clutter around for post-mortem fussing with the test cases themselves. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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-dev] Call for review / testing...
On 3/3/2016 11:34 AM, Andy Bradford wrote: I'll see if I can track it down later if there is no more progress elsewhere. Try setting TEMP somewhere sane, perhaps: $ export TEMP=/tmp $ tclsh That fixed it for me. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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-dev] Call for review / testing...
On 3/3/2016 10:53 AM, Joe Mistachkin wrote: Ross Berteig wrote: My Ubuntu VM saw this exact message. I was running tester.tcl in a testing folder that is neither the build nor source tree. My guess is that you had a pre-existing checkout recorded for that directory. Please "fossil all ignore" on that checkout manually and then try again. $ fossil all ls /home/ross/fossiltest/f.fossil $ fossil all ls -c /home/ross/fossiltest/work $ pwd /tmp/ftst $ tclsh ~/fossiltest/work/test/tester.tcl ~/fossiltest/build/fossil ... already within an open tree rooted at /home/ross/fossiltest/work/ ... I looked more closely at test_setup, and especially near its line 17 as hinted in the stack backtrace. That is where the new repo is opened. I printed [pwd] just before that line, and found that it was /home/fossiltest/work/test/repo_11880/1457033017_1/amend.test which clearly *is* inside the open checkout. Why is $tempRepoPath in the wrong place? The problem is that I don't have TEMP set at all on Ubuntu. Setting TEMP before running the test harness makes a difference, and tester.tcl runs. Running against a vanilla build of fossil, it completes and finds only known bugs. Running against a build configured with all the bells and whistles, especially --json, it blew up. Looks like it couldn't "package require json" which likely means that I last ran tests on this VM before I built the JSON tests and I need to figure out how to get the json package into its installed Tcl. I imagine that defining TEMP is the same issue Andy has. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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-dev] Call for review / testing...
On 3/3/2016 7:19 AM, Andy Bradford wrote: $ tclsh $SRC/test/tester.tcl $FOSSIL * amend ** already within an open tree rooted at /tmp/fossil-test/ while executing My Ubuntu VM saw this exact message. I was running tester.tcl in a testing folder that is neither the build nor source tree. And repeating it launched from a build tree: $ tclsh ../work/test/tester.tcl ./fossil -quiet -verbose -prot already within an open tree rooted at /home/ross/fossiltest/work The same sequence run on Windows from MSYS bash ran the test suite to completion. I don't have time to look into why at the moment, but I will try to look at it later if someone hasn't already. I am most certainly not already ``within an open tree rooted at /tmp/fossil-test/'' as can be seen from the output above... Knowing it is not just me fumbling on my VM, I'll try poke at it a little today. But I'm hoping that between Andy's and my reports of failure, that someone much more versed in the subtleties of cross-platform Tcl will spot the mistake. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] possible bug in dc72fd9624 whenadding--with-th1-hooks
On 2/29/2016 3:01 PM, Alexandru Birsanu wrote: Thanks for the explanations. Since Fossil 1.34 didn't have this issue I assumed it might be a bug not a new feature :). I've tried the following and it works great when run as root. export FOSSIL_HOME=/ mkdir /repos && cd /repos fossil new repo.fossil fossil server repo.fossil One other note. The chroot jail is strongest when the repo being served is not itself owned by root. After calling chroot(), it lowers privileges by impersonating the user that owns the repository. If that user is root, it still impersonated itself but that has little or no effect. So let some normal user own the repositories you serve, and the folder they live in. This implies that the folder containing the repository must be readable and writable by the user that owns the repository, if not actually owned by that user. Incidentally, the chroot jail feature has been in fossil for a long time. It is first mentioned in a check-in comment from August 2009, and the oldest surviving lines of code related to it date from February 2010. I don't know why it hasn't affected you before, unless your past usage has generally involved running fossil as other than root when serving files, which is exactly what would normally happen if fossil were accessed via CGI since web servers are usually not running as root. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] possible bug in dc72fd9624 whenadding--with-th1-hooks
On 2/29/2016 11:43 AM, jungle Boogie wrote: On 29 February 2016 at 10:36, Richard Hipp <d...@sqlite.org> wrote: Right. The "fossil server", "fossil http", "fossil cgi" and similar commands all check to see if they are running as root, and if they are they immediately create a chroot jail on the directory holding the repository then drop all root privileges - before reading the first byte off of the wire. Could you point to where in the code the chroot is created? The jail is implemented by enter_chroot_jail() in main.c ca. line 1463: https://www.fossil-scm.org/index.html/artifact/e75796be5338a81c?ln=1463,1523 That function is called in "fossil http", "fossil server", and "fossil ui", also implemented in main.c. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] possible bug in dc72fd9624 when adding--with-th1-hooks
On 2/29/2016 2:28 AM, Alexandru Birsanu wrote: HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set FOSSIL_ROOT to /root before make clean && ./configure --with-th1-hooks. I've also tested it with a non-root user, and that works fine. On Sun, Feb 28, 2016 at 10:46 PM, Joe Mistachkin <sql...@mistachkin.com> wrote: Alexandru Birsanu wrote: ./fossil server repo.fossil results in an "invalid home directory: /root" error when using a browser to connect. A couple of considerations that leap to mind: 1. $FOSSIL_HOME and $HOME are read at run time, in that order, and the first found is used as the home directory for this invocation. Their values at configure and build time would only affect the build tools, not the built fossil. 2. Don't build while logged in as root. That is trusting our Makefile and build system too much, not that we can't be trusted. ;-) 3. As others have said by now, when fossil is running as root, certain commands will enter a chroot jail rooted at the folder containing the repository and drop all privileges, before reading any bytes from the wire and especially before acting on anything it read from the wire. This is for your protection. 4. That chroot jail must contain certain folder and resources. Namely, anything required for fossil to run, such as the folder named by $FOSSIL_HOME or $HOME, /dev/null, /dev/urandom, and if you want your server to be able to display timeline dates in your local time zone also include /etc/localtime. 5. The error you have says that it knew that the home directory was /root, but that directory did not exist inside the chroot jail. Fossil requires a home directory to point somewhere it can read and write. 6. Working with a non-root user is expected as long as $FOSSIL_HOME or $HOME are pointing at a directory writable by that user, as it won't enter a jail and so the whole file system is available. What are your FOSSIL_HOME and HOME environment variables set to? Can you try setting FOSSIL_HOME to the right home directory prior to running with TH1 hooks enabled? -- Joe Mistachkin -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Shorter alias for FOSSIL AMEND --EDIT-COMMENT request
On 2/25/2016 4:58 PM, to...@acm.org wrote: Would it be possible to add a short version for the –-EDIT-COMMENT option of the AMEND command (just like there is for –-comment)? Something like –e perhaps? A quick check of the handy /test-all-help page for references to -e shows that no command uses it now, so it doesn't have any overloaded meanings to confuse things. The checkin command has no option at all to cause the comment to be edited (that is what happens if -m or -M are not used). If it did, I suppose that --edit-comment would be its likely name, and -e its likely short name. So it looks like that was a six character edit to the amend command. Try checkin [769bc7b4] as see if it does what you expected. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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 all remove?
On 2/19/2016 4:51 PM, Richard Hipp wrote: On 2/19/16, Warren Young <w...@etr-usa.com> wrote: Again, I think the cleanup should be automatic. But if you are still having trouble the "fossil all ignore DIRECTORY" command should manually remove the offending check-out from the list. Maybe the "-c" option is also needed - unclear. This reminded me to look, and my recent obsession with the test suite has littered my fossil all list output with all the places I ran the tests. Which leads to two observations: 1. I thought I saw code in tester.tcl to prevent that... either I was misreading, or it doesn't work for me on Windows. Both are likely. I'll take a look at that "real soon now". 2. fossil all ignore only works for precisely named repositories, or with the -c option for named directories that are open workspaces. It would be nice if a path prefix could be used. Specifically, I was hoping that C:> fossil all ignore C:\Users\Ross\Tmp\fbuild would ignore the dozen repositories (and checkouts if repeated with -c) located below that path, since that folder is an out-of-tree build of fossil where I ran the test suite. I have several more folders just like it (built with different configurations). -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Further rename stashing oddities
On 2/17/2016 6:54 PM, Andy Bradford wrote: Thus said Ross Berteig on Wed, 17 Feb 2016 15:18:12 -0800: fossil mv --hard old new; touch old; fossil stash -m "both" fails to stash with the SQLITE_CONSTRAINT message. Not for me... $ f ver This is fossil version 1.35 [7ad8230273] 2016-02-15 17:43:10 UTC $ f mv --hard old new; touch old; fossil stash save -m both RENAME old new MOVED_FILE /tmp/new/old REVERT old DELETE new $ Andy -- TAI64 timestamp: 400056c5327e Sorry for the noise, that was a slightly different edge case which does not throw an error: If, after a rename, the old file name has content but is not added to the repo, then the stash succeeds, but it will overwrite the new content in the old name without warning. I think that is the right response, as it seems generally unsafe to have any valuable content in an open workspace that is not under version control. What I meant to say was that: $ fossil mv --hard old new; touch old; fossil add old $ fossil stash -m "Boo" fails with the SQLITE_CONSTRAINT error with trunk, aka: $ ./fossil version This is fossil version 1.35 [7935571bea] 2016-02-17 22:10:58 UTC I should add the other case to the tests, as well as the related case with a fossil mv --soft and both names present on disk and added to the repo to stash.test. I'll do that after I've admitted how late (early) it is here in California. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/17/2016 7:51 AM, Warren Young wrote: On Feb 17, 2016, at 8:17 AM, Andy Bradford <amb-fos...@bradfords.org> wrote: Just to clarify, are you doing both a rename and an add on the old filename that was renamed in the same stash? I’m doing “fossil mv --hard some/file.cpp other/file.cpp” then attempting to stash all uncommitted changes. (i.e. “fossil stash save -m blahblah”) But in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg22595.html you said However, this nonstandard option is not at fault per se. This also triggers it with a default build: mv foo.c bar.c f mv --soft foo.c bar.c f stash So, the problem is trying to stash a renamed file. Using the current trunk on Windows in a 32-bit build, fossil stash correctly stashes a renamed file, if the file was also renamed on disk, and if no new file is using the old name. fossil mv --soft old new works, but the subsequent fossil stash save -m "soft" fails with "ERROR: no such file: new". fossil mv --hard old new; touch old; fossil stash -m "both" fails to stash with the SQLITE_CONSTRAINT message. Various combinations also cause fossil stash diff to complain. The stash currently is quite touchy about renamed and deleted files. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/15/2016 10:19 PM, Andy Bradford wrote: Thus said Ross Berteig on Mon, 15 Feb 2016 12:09:26 -0800: I've been seeing that same message on Windows, specifically in the context of test stash-2-1. The changeset being stashed includes a renamed file and an added file that uses the renamed file's original name. I see, yes, apparently stash doesn't handle both a rename and an add for the same file in the same stash. Is this the cause of the assert failure? I don't think so, but I don't know for sure, because I cannot reproduce the assertion failure in Windows. The test case I wrote (see stash-WY-1 in stash.test) from the OP's description of a narrowed case that reproduced the assert for him involves a stashed rename where the file on disk was not renamed. In brief: fossil mv --soft f1 f1new; fossil stash save -m "boom" On Windows, the fossil stash said: "ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new" The case mentioned above (stash-2-1) came from revert.test, which was a model for the implementation of the stash tests cases. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/14/2016 7:49 PM, Warren Young wrote: On the Linux machine I originally saw the problem on, I get a new symptom which may illuminate the cause of the assertion failure. On “stash save” it now says: SQLITE_CONSTRAINT: abort at 19 in [INSERT INTO stashfile(stashid, rid, isAdded, isRemoved, isExec, isLink,origname, newname, delta)VALUES(3,:rid,:isadd,:isrm,:isexe,:islink,:orig,:new,:content)]: UNIQUE constraint failed: stashf f: SQL error: UNIQUE constraint failed: stashfile.origname, stashfile.stashid I've been seeing that same message on Windows, specifically in the context of test stash-2-1. The changeset being stashed includes a renamed file and an added file that uses the renamed file's original name. Notably, fossil revert passes given the conditions. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/12/2016 8:45 AM, Warren Young wrote: While doing the tests detailed in my other thread (delta.c assertion failure on Linux) I came across two other oddities that seem like unrelated issues, so I’m starting a new thread for them. I think Ross Berteig ran into some of this, so please forgive any redundancy. I didn’t want these separate issues to get lost in the other thread. Redundancy is probably good ;-) While cd’d into a fossil-scm.org repo checkout, run these commands: I added this to the (growing) test/stash.test, working in a newly created repository. I create two files: f1 and f2, add them, and commit. Then I f mv --hard f2 f2n and stash. Notice two odd behaviors: 1. Apparently every file in the repository has an empty diff saved with it. (Confirmed by the “stash show” command.) And by the output of stash save, which said: REVERT f1 REVERT f2 DELETE f2n Stash show also mentions f1 with no changes. Oddly, it mentions f2n as having no changes and is silent about its name changing from f2. Now I'm curious what fossil revert and fossil diff say when the only changes were renames. I'll go poke at that "soon". > 2. The file rename is not rescheduled. It says: MISSINGzip.c Reproduced in the test case. Which I will commit any minute now. While comparing to a similar sequence with an added f3 instead of a rename, I noticed another anomaly which I will try to paint into a corner next. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/12/2016 9:02 PM, Andy Bradford wrote: Thus said Ross Berteig on Fri, 12 Feb 2016 11:53:38 -0800: 2. The file rename is not rescheduled. It says: MISSINGzip.c Reproduced in the test case. Which I will commit any minute now. I saw this too a couple days ago and began working on a fix. I believe the following will address this particular problem: http://www.fossil-scm.org/index.html/info/fea4d80ee7b880bb If someone will review and provide feedback, I'll feel better about it being merged. Thanks, Andy I poked at this change with stash.test. * It changed the output seen by fossil stash pop when it reapplied a stash containing a renamed file. It has said "MISSING old" and now says "RENAMED new". That is probably sane. * It didn't affect some of the other oddities. Not a surprise. * I had missed a detail in the output of a fossil mv --hard that caused a false positive. I also missed a cut-n-paste error in the test id of that test. * The issue is directly covered by test ids stash-3-2 and stash-3-2-show-1. Those still fail. That is, the untouched file f1 is still named with an empty diff in the stash, and is reverted when the stash is made. * But the term MISSING is not longer applied to the renamed file. * The previously failing stash-3-2-pop-changes now passes because after popping the stash, fossil changes used to say "MISSING f2" and now says "RENAMED f2n". * The test stash-3-2-pop-addremove had the wrong expected list. After popping the rename, there is no reason for fossil addremove to see any work to do. The bottom line is that this change caused me to reexamine and fix my test cases, both in your pending-review branch, and on trunk. From what I see in stash.test, it is beneficial. I think I'm going to stash my changes to stash.test on trunk until after this merges to make that merge less painful. Someone better versed in the SQL innards will have to speak to the actual changes you made, I have not evaluated it from that point of view. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/12/2016 5:39 PM, Warren Young wrote: On Feb 12, 2016, at 5:09 PM, Ross Berteig <r...@cheshireeng.com> wrote: After considering, I strongly suspect this is by design. Of course; reverting add should not remove the file. The file was not always Fossil’s to do with as it pleased, so when we revert add, we really mean “unmanage”. The file becomes someone else’s problem again, as far as Fossil is concerned. Yes. Fossil simply knows nothing about the previous lifetime of the file, so it would be presumptuous to delete it when we revert the add whether by revert or stash. I’m not certain how this plays into the stash-rename problem, though. f mv --hard tells Fossil something that f add does not: it tells it both the old and new file names. The old file name belonged to Fossil, and the new file name is *proposed* to belong to fossil, and will become so on checkin. This is an expression of intent. When you stash, that intent should be saved, and when you apply that stash entry, the intent should be restored. Yes. You've expressed my unease much better than I did. Even fossil mv --soft expresses a similar intent. It has a different set of edge cases related to when and how the file system is adjusted. Imagine that file A and B are both present, but only A is managed. I suspect that fossil mv --soft A B just means that the managed name changed from A to B, which might also mean that the *content* associated with that name just got edited if A and B's content differs. So my other source of unease is that a sequence of actions in a working folder: "checkout -- edit, debug, fuss, -- revert" might leave the folder in a different state than it was just after the checkout. This is most likely the natural result of any fossil adds, but renames, compiling, debugging, etc. can certainly also create unmanaged files in the folder. As long as fossil stash save and fossil revert would leave the folder in the *same state* I think my unease is tamed. If you really want a folder that looks like a fresh checkout of some other tag or version, then you want update or checkout, or possibly even open and checkout in a new location. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] Further rename stashing oddities
On 2/12/2016 11:53 AM, Ross Berteig wrote: While comparing to a similar sequence with an added f3 instead of a rename, I noticed another anomaly which I will try to paint into a corner next. Ok, I chased this into a corner with a test case, and got all the way to the corner apparently without a bug. I now believe that what I saw was by design. In a clean repo with files f1 and f2 added and committed, I created and added a new file f3. Then I did fossil revert, which said "UNMANAGE f3" but *did not delete the file*. Subsequent testing via the test-stash command made note of f3 because it was still present in the file system. After considering, I strongly suspect this is by design. Fossil help revert is silent on the effect of reverting fossil add, other than to say "Revert to the current repository version of FILE, or to the version associated with baseline REVISION if the -r flag appears." While revert generally is intended to destroy information (revert all changes does that) it could be argued that reverting add by simply doing UNMANAGE is the least action to take. On the other hand, that could lead to surprises. The fossil regression test suite is made up of test/*.test, regardless of whether those files are managed by fossil or not. Adding a test file, then reverting to remove it would not change what tests are run *in that workspace*. So the ghost I thought I saw was extra references to f3 after it was already out of the picture. I think that was the intent of the current implementation. But is it the right answer? I don't know for sure. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] ./src/delta.c:231: checksum: Assertion failed
On 2/11/2016 10:06 AM, Ross Berteig wrote:
What does fossil revert do in this circumstance?
It says:
REVERT f1
DELETE f1new
"fossil undo" is available to undo changes to the working checkout.
and has now forgotten the pending rename.
I think that fossil stash save *should* do the same thing. It doesn't.
I've updated the test case in stash.test to call this a knownBug.
While looking at revert.test, I noticed another interesting edge case
surrounding renames:
$ fossil mv f1 f1old
$ mv f1 f1old
$ echo "hi" > f1
$ fossil add f1
$ fossil revert
Replacing "revert" with "stash" causes SQLite to freak out:
SQLITE_CONSTRAINT: {abort at 19 in [INSERT INTO stashfile(stashid,
rid, isAdded, isRemoved, isExec, isLink,origname, newname,
delta)VALUES(1,:rid,:isadd,:isrm,:isexe,:islink,:orig,:new,:content)]:
UNIQUE constraint failed: stashf}
This is now tested in stash.test, and also marked as a knownBug.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
___
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] We strongly feel that the code and issue tracker...
On 2/11/2016 5:16 PM, Stephan Beal wrote: On Thu, Feb 11, 2016 at 11:08 PM, bch <brad.har...@gmail.com <mailto:brad.har...@gmail.com>> wrote: https://github.com/eslint/eslint/issues/5205 They want... Requirements * Must host the repo along with the related tools Not fossil alone. But Chiselapp could be grown upon with non-negligible effort to provide social interaction tools like Github's. It would be a lot of work to do it right, and most of that work would be outside of fossil's core mission. * Must be able to run automated tests on pull requests As I understand it, that sort of thing should be possible for us now through the hooks and scripting capabilities. Someone should set up some working examples with lots of documentation about how to really do it and what the pitfalls are. * Must allow contributions from anyone We have the whole user authentication system for the core team, and bundles (and I suppose patches as a fallback) as transport for requests from outsiders. * Must have a way to setup issue templates prescribing what fields are required * Must have ways to organize issues other than labeling (milestones, priorities, etc.) Our default ticket schema hint at the way to go, but doing that right would require some extensive work on the schema and reports, and may still require supporting Tcl or TH1 scripting. * Must import existing GitHub issues and pull requests Git import is steadily improving. GitHub is greater than just Git, and that is were things will get interesting. One piece of friction that leaps to mind is that GitHub's dialect of Markdown is different from ours. That last one would be a killer. The second one implies that it must have a git back-end (or something equivalent to a pull request). Lots of friction there. But perhaps achievable if someone got a bee in their bonnet and took it on as a personal mission. That won't be me, I've bitten off plenty by getting involved in regression tests. It shouldn't be Stephan, we need him to finish libfossil and support everything else he's touched *without aggravating his elbow. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] ./src/delta.c:231: checksum: Assertion failed
On 2/10/2016 10:41 PM, Andy Bradford wrote:
Thus said Ross Berteig on Wed, 10 Feb 2016 15:48:40 -0800:
which as expected renamed the file in the repository but not on the
disk. It then says
fossil stash -m "B 2016-02-09"
Did you mean:
fossil stash save -m "B 2016-02-09"
Yes, typo in transcribing to email. The actual command is buried inside
test/stash.test inside a call to stash-test. (In the current checkin,
hidden inside an if {false} {} block pending this discussion.)
ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
What was fossil stash supposed to do in this circumstance?
It marked the file as being renamed but did not change the disk, as
documented in ``fossil help mv'':
Right. "It" being fossil mv, not fossil stash save. That seems to be the
condition in which the OP reports seeing the assertion fail at
delta.c:231, which I'm trying to replicate in a test case.
You asked Fossil to prepare the repository for a file move, but never
moved the files. Then when you attempted to stash the change, Fossil
complained because it expected to find f1new, but you never renamed f1
to f1new. If you had also then done ``fossil status'' it would have
reported f1new as MISSING.
So is this the expected behavior then?
Fossil help stash says "save the current changes... as a new stash" but
is silent about the case of a rename marked in the repo but not
completed on disk.
Since the purpose (as I understand it) of the fossil stash command is to
allow partially completed work to be set aside and recalled later, it
seems logical (and necessary) that renames are part of what it saves.
What does fossil revert do in this circumstance?
It says:
REVERT f1
DELETE f1new
"fossil undo" is available to undo changes to the working checkout.
and has now forgotten the pending rename.
I think that fossil stash save *should* do the same thing. It doesn't.
So what I'm really asking here is whether that MISSING error produced by
fossil stash save represents a bug (shortcoming at least) in the
documentation or a bug in the stash itself?
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
___
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] ./src/delta.c:231: checksum: Assertion failed
On 2/10/2016 7:35 AM, Warren Young wrote: However, this nonstandard option is not at fault per se. This also triggers it with a default build: mv foo.c bar.c f mv --soft foo.c bar.c f stash So, the problem is trying to stash a renamed file. Given this nice, concise, and obviously minimal script to cause fossil stash to fail, I added it to our regression tests. First I had to create test/stash.test which I modeled after test/revert.test since there are huge similarities between fossil stash save and fossil revert both in function and in output. Two interesting results turn up from that effort. First, I don't reproduce the assertion failure on my 32-bit Windows build. This might not be surprising at all, it could absolutely be a quirk of having 32-bit integers and 64-bit pointers as documented for the OP's configuration. Second, I don't get a stash saved at all. My case starts from a clean checkout that has three unedited files. It does fossil mv --soft f1 f1new which as expected renamed the file in the repository but not on the disk. It then says fossil stash -m "B 2016-02-09" which says ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new and does not create any stash entry. What was fossil stash supposed to do in this circumstance? The early test case (modeled after fossil revert's behavior) modeled the stashed rename oddly as well, but at least it did model it. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
