Re: [fossil-users] clone a repository over ssh where the path includes whitespace characters
On Thu, Aug 8, 2019 at 10:20 AM Poor Yorick wrote: > > Hello, > > Attempting to clone a repository over ssh where the path contains whitespace > characters: > > fossil clone 'ssh://user@domain://path/to/directory with spaces/my.fossil' my.fossil > > Various attempts, including percent or plus encoding, all fail. Is there some > incantation that works? This mailing list isn't used any more. The current support forum is: https://fossil-scm.org/forum/ That said, i'm going to take a wild guess as to a workaround: fossil clone 'ssh://user@domain://path/to/"directory with spaces"/my.fossil' my.fossil (Note the extra quotes.) i've no idea if that will really work, though. -- - stephan beal https://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Different file count after FOSSIL REBUILD --COMPRESS
On Mon, Apr 8, 2019 at 12:36 AM Tony Papadimitriou wrote: > (Apologies if this message appears twice – I’m having some SMTP issues.) > This mailing list isn't used any more. The forum is now the preferred channel: https://fossil-scm.org/forum > I attempted to minimize storage by running “fossil reb --compress” on > various fossils. Only one result was unexpected. > Below is a copy of the db --db-check before and after a REBUILD with > –-COMPRESS option. The ‘after’ is counting one file less. > > 1. What could be the reason for that (4299 files instead of 4300)? > Possibly a shunned artifact. 2. Is there some way to find out which file is missing by comparing to a > backup? > You can use use sqlite's "ATTACH" command to attach both the new and old DBs and do a SELECT to find the extra blob.uuid entry in the older copy. There's a CONTENT() SQL function (via fossil's built-in copy of the sqlite shell) to get the full, uncompressed content of a blob, but it outputs using sqlite's hex-encoded mode, and i'm not sure how to get it unencoded: echo "select content('rid:1')" | fossil sqlite3 -R repofile replacing 'rid:1' with the UUID of the newly-missing artifact. 3. Is it safe to assume (based on the db –db-check command) that the repo > is not corrupt in any way? > Definitely. -- - stephan beal https://wanderinghorse.net/home/stephan/ <http://wanderinghorse.net/home/stephan/> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Corrupt database at first commit after a Fossil update
On Thu, Nov 8, 2018 at 2:15 AM Zoltán Kócsi wrote: > Oh. That's really, really sad. I much prefer mailing lists to any web > based forum. Most of us do as well, but: bots and spammers are making it ever more difficult to manage mailing lists. The forum can send you mail notifications, but replying requires going through the forum. (i don't know if there are plans to eventually support replies via email.) Unlike the mailing list, the forum allows anonymous posts, but such posts are always moderated before they're visible to the public. "So far" we haven't had any spammers/bots on the forum, but that might be because it's not yet a big enough target for them ;). Well, times are a changin'... > We have the spammers and their bots to thank for that :/. -- - stephan beal https://wanderinghorse.net/home/stephan/ <http://wanderinghorse.net/home/stephan/> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Corrupt database at first commit after a Fossil update
On Thu, Nov 8, 2018 at 1:13 AM Zoltán Kócsi wrote: > I've updated Fossil from 1.29 to 2.7 on the server and on a client. The > database files on the server were left alone. > PS: this mailing list is no longer active. Please use the new forums for future questions: https://fossil-scm.org/forum -- - stephan beal https://wanderinghorse.net/home/stephan/ <http://wanderinghorse.net/home/stephan/> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why no EXE+DLL like SQLite?
On Tue, Aug 7, 2018 at 4:15 PM Donald Griggs wrote: > Re: http://www.tortoisefossil.org/index.cgi/index "What you'll find > here is a work in progress " > > Unfortunately, it appears the project is at least on hiatus, if not > abandoned. The last code commit in the timeline was in late 2014. > That time frame is familiar to me, so i had to check... a couple timeline entries mention his use of libfossil, and late 2014 was when chronic RSI knocked me out of my hobby projects (which included libfossil). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] "fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?
If it was that common we would have realized the problem sooner ;). The problem with generating output for "no changes" is that we potentially break any automation which relies on an empty diff to mean "no changes". (That lnly applies to "diff", not gdiff.) That could, i guess, be "fixed" by adding a --quiet option, suppressing any non-diff output. Something to consider, in any case. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Sat, Aug 4, 2018, 17:11 Gilles wrote: > On 04/08/2018 16:43, Stephan Beal wrote: > > That means there are no diffs to show. Try: > > fossil gdiff --from prev test.html > > That was it. > > Grrr, I should have thought about it :-/ > > I don't know how common this mistake is, but if it, it might be a good > thing if Fossil said something like "No change." > > Thanks much everyone. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] "fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?
On Sat, Aug 4, 2018 at 4:25 PM Gilles wrote: > On 04/08/2018 15:51, Gilles wrote: > > d:\Temp>fossil gdiff test.html > > > > Nothing. > > I don't know if it means anything, but incidently, "fossil diff" doesn't > return anything either: > > d:\Temp>fossil diff test.html > > d:\Temp>fossil finfo test.html > That means there are no diffs to show. Try: fossil gdiff --from prev test.html -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil's (lack of) use of the Ticket system
On Sat, Aug 4, 2018 at 12:38 PM Gilles wrote: > A lot of "How do I…?" questions can be answered by searching the archives > of the mailing list : > > https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/ > People don't do that, though. In every support forum in the universe, some appreciable percentage of posts are asking the same thing which the fellow 3 posts down from them is asking. (The BoardGameGeek forums are _prime_ examples of this.) Since it's apparently not mentionned currently — I had to google "fossil > scm mailing list" to find it —, I suggest updating the Docs section of > www.fossil-scm.org page to add a link. > Richard is in the process of replacing the mailing list, so it's unlikely to get a link on the home page. > And maybe one day, move the mailing list to a web-based forum entirely so > that people can post questions directly. > That's exactly what Richard is currently implementing. That alone won't stop the "how do i" posts - it's a Cosmic Rule that many people won't bother searching a forum (beyond a casual Google effort) before posting their own (oft-repeated) query. :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil's (lack of) use of the Ticket system
On Fri, Aug 3, 2018 at 8:11 PM Dan Barbarito wrote: > I am trying to understand why Fossil itself does not use the built-in > ticketing functionality. I understand that trolls + spammers may be a > problem, but can't ticket changes simply be approved/denied? Using the > ticketing system would give more people the opportunity to understand what > bugs are being worked on, what features are being added, etc. Having a > single place to document bugs and feature requests is the best way to see > the status of a project at a glance. Yes, we have this mailing list and > soon we will have forums, but I don't think bug reports should reside in > these places. > Fossil used to use its own ticketing system more, but experience showed that it was simply less hassle to use the mailing list. That certainly isn't true for all projects. In the majority of cases, reported bugs are literally not bugs - they're misunderstandings of how to use fossil. A large portion of the "real bugs" reported often ended up resolved within hours of someone reporting them on the mailing list, making the administration via a ticket system more overhead than it was worth. Yes, there's always that minority of bugs for which tracking them in the ticket system makes sense, but it simply fell out of fashion to do so. i see that Richard just answered, so i'll stop there and see what he says on the topic. If there's any conflict of opinions, he wins, of course ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CMake project for Fossil development using IDE [branch: cmake-ide]
On Thu, Aug 2, 2018 at 12:59 PM Artur Shepilko wrote: > The rationale is to leverage the usual IDE conveninces such as code > browsing, auto-complete, visual debugger etc. Also, having a Fossil > source control plugin helps navigating the changes. > One forewarning about code browsing: the build process filters the files under src/, copying them to bld/, which means that if you accidentally browse (via "symbol-following" features) into bld/*.c and start editing, any changes will be lost the next time you build. Been there, done that. Also, many C files under src/ use custom markup (lines starting with @) which will confuse most C editors (any which do syntax highlighting). That's only "cosmetic confusion", though - it doesn't break anything. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backup traffic
On Fri, Jul 20, 2018 at 10:13 AM Florian Balmer wrote: > I have created a (surprisingly simple) patch to attach a separate > login cookie database (shared among all repositories in the same > directory), so that plain login and logout actions will no longer > cause repository database writes. With admin and user logs turned off, > and "PRAGMA optimize" removed, the repository database is only touched > if there's new contents, or new configuration settings. > > What's your comments to this? Does anybody care about the repository > database, holding all your valuable contents, being modified > frequently with simple non-contents state information? This behaviour doesn't bother me at all (in 10 years of using Fossil), but if a patch for working around it is simple and non-intrusive, i would consider it to be an interesting feature (with the caveat that it might impact future changes). i conceptually like the idea of the login cookie/timestamps being in a separate db, but i'm not sure that i like it enough to justify the idea of maintaining two files where one file is sufficient. That wouldn't really impact me much, as i keep all of my hosted .fsl files in one directory, but for a hoster like chisselapp, where each repo is (probably) in its own directory, it doubles the number of fossil-related files. One _potential_ problem i see, but it's largely hypothetical, is that the login cookie db could become a point of locking contention if is used together with many very active .fsl files. That is probably only possible if several of those repos are _extremely_ active, though. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Can't believe --branchcolor would be platform-specific
On Sat, Jul 7, 2018 at 2:12 PM Martin Gagnon wrote: > My guess is that on a bash shell, # is the symbol for comments. Try to put > it in double quotes; >e.g.:—branchcolor "#f0a0a0" > That is definitely what's happening, and it's not bash-specific: every[^1] Unix-style shell known to man treats an unescaped # as the start of a comment. An alternate approach, aside from quotes is: --branchcolor \#f0a0a0 [1] = obviously, since i say "every" in public, someone will now point out an exception to that rule. That said, i'm not aware of any exceptions. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Segfault on json test
On Thu, Jul 5, 2018 at 5:38 PM Dingyuan Wang wrote: > Hi, > > The following test: > > tclsh test/tester.tcl fossil json > > fails with: > > [...] > /home/gumble/dev/fossil/fossil json --json-input anon-1 > ERROR: child killed: segmentation violation > https://www.fossil-scm.org/index.html/info/f488a5aa97a3b15f There are still 2 json tests which fail, but i didn't write those and can't say anything useful about them :/. The segfault is resolved, in any case. Thanks for the report! -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Segfault on json test
On Thu, Jul 5, 2018 at 5:38 PM Dingyuan Wang wrote: > The following test: > > tclsh test/tester.tcl fossil json > > fails with: > i believe the fix is simply: [stephan@host:~/fossil/fossil]$ f diff Index: src/cgi.c == --- src/cgi.c +++ src/cgi.c @@ -211,11 +211,12 @@ const char *zValue, /* Value of the cookie. Automatically escaped */ const char *zPath,/* Path cookie applies to. NULL means "/" */ int lifetime /* Expiration of the cookie in seconds from now */ ){ char *zSecure = ""; - if( zPath==0 ){ + if(!g.isHTTP) return /* likely JSON CLI mode */; + else if( zPath==0 ){ zPath = g.zTop; if( zPath[0]==0 ) zPath = "/"; } if( g.zBaseURL!=0 && strncmp(g.zBaseURL, "https:", 6)==0 ){ zSecure = " secure;"; but i need to test more before committing. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown wiki relative links
i don't _think_ that you can use %2f in a path component and have it apply different semantics than a slash. How would software know to differentiate between the two? That would be similar to expecting a local file name of a\/b to work. (If it did work, it would cause no end of confusion.) - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 23:26 Andy Goth wrote: > On 07/04/18 16:01, Stephan Beal wrote: > > Fwiw, a few years back i created a patch which caused generated wiki > > links to always emit wiki/x rather than name=x, but it was pointed out > > to me that wiki/x doesn't work when x contains a slash, which is a valid > > wiki page name character. Thus the portable approach is to use name=x. :/ > > Well, I totally forgot slashes could be in page names. What about %2f? > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown wiki relative links
Fwiw, a few years back i created a patch which caused generated wiki links to always emit wiki/x rather than name=x, but it was pointed out to me that wiki/x doesn't work when x contains a slash, which is a valid wiki page name character. Thus the portable approach is to use name=x. :/ - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jul 4, 2018, 22:54 Andy Goth wrote: > To create a link in the Markdown wiki, the syntax is [like this](url). > That's all well and good, but what precisely does url need to be for one > page to link to another? In writing embedded documentation, I've gotten > used to relative paths, so in order to link /doc/trunk/doc/foo.md to > /doc/trunk/doc/bar.md, I write (bar.md). > > However, with the wiki, there's an issue. Most (if not all) of the > links into the wiki use the ...?name=page syntax rather than the > theoretically equivalent .../page syntax. This throws off relative > paths entirely. Relative links between wiki pages will be different > depending on which "equivalent" syntax was used to access the wiki. > > Suppose wiki page foo wants to link to wiki page bar. If foo was > accessed as wiki?name=foo, then it must link to (wiki?name=bar) or > (wiki/bar). But if foo was accessed as wiki/foo, it must link to (bar), > which it what I hoped would work all along. > > To make intra-wiki links work regardless of which syntax is used to > access the wiki, it appears it's necessary to use "absolute" (actually > relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar). > This is not something I've had to deal with (yet?) when doing embedded > documentation. > > My preference would be for Fossil to never send the name query parameter > to the user. If a name query parameter is received from the user, I > think maybe Fossil should not call the webpage function (other than > confirming that one exists) and instead immediately send a 301 Moved > Permanently back to the user to rewrite the URL to use /. > > Or maybe I'm missing something fundamental here. > > There's one other style of relative link I'll mention: (?name=bar). > This replaces the name query parameter. I don't think this would work > very well if linked from /wiki/foo. Also it gets even weirder when > clicking a link in the preview shown by wikiedit, since it takes the > user to the editor for the target page. But this last would still occur > should we replace all ?name= with /. To avoid that, the link would have > to be either (/wiki/bar) or (../wiki/bar), though of course that last > one combines the worst of all worlds. > > For now, I'll make sure all my wiki links are to /wiki/whatever. > > Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's > what Chiselapp uses. > > -- > Andy Goth | > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On Tue, Jun 26, 2018 at 5:45 PM wrote: > Can unversioned files respect their original paths when added? > I have several locations for bitmaps, icons, pdf's, etc. > They do not necessarily reside in an isolated folder. > That wouldn't work cross-platform. You might store file the C:\D\e\f.txt which i could not extract on Unix because we don't have drive letters. If we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless i was the root user. Case sensitivity is another problem in that regard. If you store C:\D\e.txt and C:\d\e.txt, those would map to two different folders on Unix systems. Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive should it use?). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Mon, Jun 25, 2018 at 2:30 PM Warren Young wrote: > On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal > wrote: > >> Isn't adding hundreds (literally) of gotos just as fraught with >> opportunities for failure ;)? >> > > #ifdef LIBFOSSIL > # define FOSSIL_EXIT(n) longjmp(blabla) > #else > # define FOSSIL_EXIT(n) exit(n) > #endif > Yeah, i was exaggerating, but still... i think the required effort is being underestimated by at least an order of magnitude. That said: i would _absolutely love_ to be proven wrong. $ sed -i -e 's/exit(/FOSSIL_EXIT(/g' src/*.c > i recommend a slight variation: perl -i -pe 's/\bexit\(/FOSSIL_EXIT(/g' src/*.c sed probably also has a \b (at-word-boundary) equivalent, but i'm not as well-versed in that flavor of regex. Sidebar: i once corrupted a fossil checkout db by using $(find . -type f) as my target for some perl -i-style refactoring :|. Never perlify your sqlite db files. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Sun, Jun 24, 2018 at 11:19 PM David Mason wrote: > I really don't understand the reticence to use setjmp/longjmp to turn all > of these short-cut exits into library return-to-API trampolines. It > To be clear: that's my reticence, not Richard's. libfossil was always effectively a third-party effort which had Richard's blessing. My aversion to setjmp/longjmp is that they're effectively global gotos, and gotos, except in very tightly-controlled circumstances, quickly produces spaghetti messes. would allow you to retain all the existing fossil codebase. Rewriting the > code into library form is an interesting project, but it seems like a huge > amount of work and unless Richard is going to change fossil to use the API, > it is also going to be a huge ongoing maintenance nightmare and fraught > with opportunities for failure. > Isn't adding hundreds (literally) of gotos just as fraught with opportunities for failure ;)? It's a few dozen lines of code (in addition to the actual API interface > code). Sure seems like worth the experiment to me! > i'll go make some popcorn :). (To be fair: my [strong] aversion to that solution isn't intended to imply that you can't pull it off. My journey with libfossil was always _at least_ as much about reimplementing it "cleanly" as it was about getting it running at all. Without the former, the latter would have been, at best, a hollow success.) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] No rule to make target 'src/email.c', ...
Richard just fixed that moments ago - update again and it will work. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Jun 20, 2018, 22:02 Sergei Gavrikov wrote: > [FYI] > >$ f info >project-name: Fossil >... >project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 >checkout: 25eafed11494e801c28babfbc5784f877c3aa0b7 2018-06-20 > 19:04:04 UTC >parent: 9a2e5f47170b4f2d86e23c1b2cb37d5b284e7982 2018-06-20 > 18:47:46 UTC >tags: trunk >comment: Add a new capability that allows signup for email > notification. > Change the name of the older "EMail" privilege to > "View-PII" to > avoid confusion. (user: drh) >check-ins:11308 > >$ make distclean && ./configure --quiet && make -s >rm -rf bld/* fossil >rm -f autoconfig.h config.log Makefile >make: *** No rule to make target 'src/email.c', needed by > 'bld/email_.c'. Stop. > > -- > sg > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Tue, Jun 19, 2018 at 8:13 PM Sam Putman wrote: > >> >>> I got the sense from the docs that the hash is using the SQLite style >>> versioned API, so it follows that >>> the old hash code is sitting where it needs to. >>> >>> Does this amount to following the style of that file for another similar >>> file in fossil(1)? >>> >> >> i'm not clear what you mean :|. >> >> > I'm sure that could have been more clear. > > Did some poking around between fossil and libfossil, it looks like they > both have a sha-1.c, > the difference starts with the copyright, 2006 vs 2013. A cursory scan > suggests that the ~200 > line difference is more tests, and some framework code that presumably > libfossil doesn't need. > > fossil also has sha1-hard.c (let's ignore this for now?) and sha3.c. > > I haven't yet found where in libfossil sha-1.c is called, and what the > substantive differences > are between the two. What I'm wondering is, can the wrapper for sha-1.c > be rewritten to also > wrap sha-3? Possibly sha1-hard as well, if it's on a critical path. > A few of the utility classes (most notably sha1 and md5) were originally copied over 1-to-1 and renamed to match the libfossil project conventions. sha1-hard and sha-3 came along after my RSI fallout, and are not included in libfossil. i have _no_ idea what the differences are between sha1 and sha1-hard, so can't comment on those. The buffer sizes differ between sha1 and sha-3, so i'm not sure whether those two could be reasonably/cleanly combined. i have to resist the temptation to go poking around in the code rabbit hole, as that almost invariably leads to days of hand pains :(. (Software development was always like a drug to me, and i am very much a recovering addict.) I know there's some wrinkles around how fossil picks a sha that allowed for > the transition, I'm > content with being able to wield those sha functions in a fossil context > at a fairly low level, for now. > It "should" be trivial to port the core sha1-hard and sha-3 to libfossil - porting of sha1 and md5 was literally a copy/paste/rename job. However, the assumption that SHA1 is "the" hash is "strongly embedded" in many places in libfossil (md5 is only used in the manifest files and its usage does not need to be modified/extended). It "should" be simple to find all such places by grepping for FSL_UUID_STRLEN (defined in include/fossil-scm/fossil-hash.h), and porting all such places to support variable hashes is, AFAIK, the only critical piece needed for making libfossil compatible (again) with fossil(1). If that hurdle can be surpassed, the rest is "easy" (even the merging - it simply needs to be ported over from fossil, adapting the API to a library interface along the way). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Are commits with "a lot" of small files still an issue?
On Tue, Jun 19, 2018 at 7:56 PM Martin Vahi wrote: > The reason, why I write the current letter > is that IF the insertion of large amounts of > very small files is still an issue, then > there would be an opportunity to fix it > before anybody reports the issue. > i think we're all curious what you mean by (1) "large amounts" of files (hundreds, thousands, tens of thousands?) and (B) "is still an issue"? Have you had problems importing hundreds or thousands of small files? And what were the problems? -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Mon, Jun 18, 2018 at 7:18 PM Sam Putman wrote: > A Capitalized pure-C struct being referred to as an object is not unheard > of! But it did lead me down > the wrong path. > Here's my little contribution to spreading the word about OO in C: http://www.wanderinghorse.net/computing/papers/DoingOOInC.pdf :) > I got the sense from the docs that the hash is using the SQLite style > versioned API, so it follows that > the old hash code is sitting where it needs to. > > Does this amount to following the style of that file for another similar > file in fossil(1)? > i'm not clear what you mean :|. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Sun, Jun 17, 2018 at 11:11 PM Sam Putman wrote: > On Sun, Jun 17, 2018 at 6:39 AM, David Mason wrote: > >> Just had a quick thought that might make the conversion to library much >> easier. >> >> If you have a relatively small API interface, each of the API functions >> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h >> > > This is the kind of approach I glossed over as a "goto cleanup", so we're on > the same track here. > > I haven't had a chance to go over some of the core C files in libfossil > yet, > curious to what degree it follows this pattern already. > i have to admit that you lost me at setjmp. There are certain C APIs which i won't touch unless absolutely forced to, and setjmp/longjmp belong to that category. gotos are widely used in libfossil to simplify error handling/deallocation within a given function. In libfossil, all error state is propagated as an integer, with some cases providing additional information in an Error object owned by the Context object (each Context manages, at most, one opened repo instance). The API docs describe, where relevant, which result codes must be considered fatal/unrecoverable (allocation error being the primary case). An example of propagating more information is SQL query preparation failure - the error string from sqlite would be propagated back up via the Context's Error object. An allocation error, on the other hand, is simply returned as the enum entry FSL_RC_OOM, as we can't provide more information for that case without more allocation (which would presumably fail). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Sun, Jun 17, 2018 at 11:07 PM Sam Putman wrote: > About those objects... > > What your docs call fossil(1) is written in plain C. Or rather C, Tcl, SQL > and TH1, if you prefer. > In any case, not C++. > liubfossil is 100% C89 except that it requires "long long" because sqlite3 requires it. long long is not strictly C89 but all compilers supports it. The C++ code in the tree is simply optional high-level wrappers, intended primarily to allow me to "exercise" the core API, to make sure that it would be useful in other contexts. > I'm still pretty convinced the work on libfossil won't go to waste. > > The excellent documentation alone has advanced my understanding > considerably. > :) > What might make sense is a sort of 'parallel construction'. Nice thing > about a revision control > system, it's got all the revisions. > > So to write a clean C libfossil, we can start with the first commit and > follow the breadcrumbs. > The only "problem" with that (for a given definition of "problem") is that i'm rather chaotic in terms of how i work on code: there's little rhyme or reason, nor any specific ordering to commits or (for the most part) features. You won't find any reasonable order to the timeline. The implementation required, of course, certain features before others, though, so... there is that. > I don't think it's strongly tied to the patch-centric model, it's a > (relatively) simple matter of > representing possible outcomes as distinct states. There might be some > potentially > exponential bad behavior, we are talking about permutations after all. > It might even be feasible to store each such variation in the 'stash' table (llibfossil never got far enough to implement the 'stash' or 'undo' parts, as both depend on the merge process, which was the final "big/scary" hurdle left to port). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backups of deconstructed fossil repositories
On Sun, Jun 17, 2018 at 10:08 PM Warren Young wrote: > On Jun 17, 2018, at 2:05 PM, Warren Young wrote: > > > > If you’re willing to gamble that if the first test returns true that the > second will also returns true, it buys you a big increase in speed. The > gamble is worth taking as long as the files’ modification timestamps are > trustworthy. > > I just remembered something: “fossil up” purposely does not modify the > mtimes of the files it writes to match the mtime of the file in the > repository because it can cause difficult-to-diagnose build system errors. > Writing changed files out with the current wall time as the mtime is more > likely to cause correct builds. > To that i'm going to add that fossil doesn't actually store any file timestamps! It only records the time of a commit. When fossil is asked "what's the timestamp for file X?", the answer is really the timestamp of the last commit in which that file was modified. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Change textarea for textnotes to placeholder text
On Sun, Jun 17, 2018, 15:26 Zack Scholl wrote: > > > [1]: https://www.w3schools.com/tags/att_textarea_placeholder.asp > > [2]: > https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a > Just fyi: the ln= param accepts both a single line number or range of lines (e.g. ln=20-30): https://www.fossil-scm.org/index.html/artifact?udc=1=544=5d4a12252f765b5a - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. ___ 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 fossil library
type of merging decisions which are made during, e.g., a checkout). Speaking of merging: that's often an interactive process, and interactivity is difficult to define in a UI-ignorant library. > The one area of fossil I've done enough reading into to feel comfortable > in my understanding is the > file format itself. There's an edge to the documentation and I'm kinda > peering over that edge slightly. > The "artifact format" documentation is really Fossil's heart. All of the other parts are implementation details for supporting that. Nonetheless, any port will certainly want to take advantage of as many of those details as possible (much of fossil's "heavy lifting" is done with sqlite, and reimplementing many of those pieces without sqlite would be a massive undertaking). i would be thrilled to see someone implement a library for fossil, but >> anyone doing so needs to understand, in advance, that it's a large >> undertaking. >> >> > I'm happy to sign contribution agreements and otherwise smooth the way to > collaborating on this. > None are needed if you just want to access to libfossil (initially they were, but that requirement was later dropped). If you'll send me your preferred user name off-list i'll get it set up. Thanks again, Stephan. I'll be looking into those links, please don't feel > as though a back-and-forth on each > email is necessary, whatever is comfortable for you. > My hands have "good days" and "bad days", but today's relatively good. In any case, every now and then i have to sit down and type for a while just to see if my hands can take it. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Sat, Jun 16, 2018 at 12:07 PM Stephan Beal wrote: > libfossil had essentially all of the core-most functionality > running (documented, too) > http://fossil.wanderinghorse.net/repos/libfossil/doxygen/ Ah, those were the days... (i actually _miss_ documenting software.) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On Sat, Jun 16, 2018 at 12:46 AM Stephan Beal wrote: > i will write a longer response when i'm back on the PC, but short version: > > - refactoring to a lib is a huge effort. > ... > More details upcoming about that first point in the morning. > So... http://fossil.wanderinghorse.net/r/libfossil that's now effectively defunct, though, as i've been on medical leave for RSI most of the past 3.5 years and am currently on track to be forced into early retirement within the next couple of months. Several aspects of fossil make it very tedious (but not difficult, per se) to port to a library: 1) it uses a great deal of global state. That's simple enough to factor into a Context object, but... 2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error will immediately (intentionally) crash the app. While that saves literally half (sometimes more) of code/error checking any place where memory is allocated (that's a lot of places), that pattern is unusable for libraries. Granted, allocation errors are rare, but every single C call which allocates has to check for failure or risk Undefined Behaviour. To simplify the vast majority of the implementation, Fossil does this checking in a single place and abort()s the app if an allocation fails. 3) Fossil effectively uses exit() to handle just about any type of non-allocation error. i.e. there's little library-friendly error handling in fossil. 4) Last but not least: Fossil implements a great many intricate algorithms which, if not ported 100% perfectly, could lead to all sorts of Grief, some of it difficult to track down. Such ports typically require 2x as much code, sometimes more, because of the addition of error checking and handling (as opposed to using abort() and exit()). libfossil had essentially all of the core-most functionality running (documented, too) when RSI knocked me out, and was mainly missing network-related functionality. It took, according to the timeline, about 16 months to get it to that point (noting that i also worked on other projects at the time, so that's not "16 months of effort"). My plan was to pick it back up when my RSI problems passed, but whether they will is now an open question. In the mean time, the SHA-related changes have made libfossil incompatible with fossil, meaning that it would be much more difficult to get it back up and running. i would be thrilled to see someone implement a library for fossil, but anyone doing so needs to understand, in advance, that it's a large undertaking. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
i will write a longer response when i'm back on the PC, but short version: - refactoring to a lib is a huge effort. - up until late 2014 i was actively working on a library port and had most of the core features working. - RSI struck me down and has since effectively removed me from the programming world, so libfossil has remained unmaintained and is not longer compatible since the addition of non-SHA1 hashes (and i have no estimate for what it would take to bring it up to date). More details upcoming about that first point in the morning. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Fri, Jun 15, 2018, 22:26 Sam Putman wrote: > First post. Hi! > > I've been lurking along, following the discussion here. > > Common thread is a desire for 'more fossil'. I'm in this camp myself. > > But I see the attraction of the core fossil application. It works perfectly > for a fairly close-knit community, and it follows a philosophy that's been > working for decades now. One that is, if anything, more effective as it > becomes less fashionable. > > Let me make a suggestion: what we need is not more fossil, it is less > fossil. > > I wrote Dr. Richard Hipp about this earlier, his response was positive > enough > that I felt encouraged to bring it to the community. > > For my own projects, I've switched to fossil. It's the obvious choice, > we're > using SQLite in preference to the old pile o' files already. > > The fossil codebase has all the core algorithms for storing deltas in a > single database file, merging, deduplication, Merkle hashing, key signature > management, extensible metadata... I don't have to sell you on the virtues > of this VCS! > > I would benefit greatly from being able to use this excellent collection of > SQLite best practices and algorithms, the same way I use SQLite: as a > static > or linked library, one which can be wrapped in various FFIs for VMs, or > linked > directly from a systems language. > > My own case would call this from LuaJIT, what matters is everyone can be > happy. fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it > should, and adventurers could wire it to mailing lists, wikis, forums. > > I think this would help fossil really stand out. Just the fact that here > we > have tools to read and write git to a single-file database, that's huge! > > Tools for revision control would be a real boon to applications already > using > SQLite as an AFF. I could go on. > > I always feel some trepidation towards what amounts to asking other people > for > free work. I feel this refactoring could benefit fossil as well as my own > software. I'd be a part of such an effort as soon as anything halfway > plausible > was compiling, if invited. > > Sincerely, > > -Sam Putman > -- > Special Circumstances > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 10:51 PM Ron W wrote: > In another forum I follow,a commented claims that Fossil is designed for > "cathedral development" not "bazaar development", so would be of little > interest to anyone. Unfortunately, the poster did not elaborate on why. > Maybe he's just young and full of beans. Maybe he's equating "bazaar" with one of its more extreme implementations, "github". Or maybe he's not aware of the scope of the term "bazaar", which, n this context, predates all DVCSs that i can find record of via: https://en.wikipedia.org/wiki/Distributed_version_control#History That term was already in use by the time ESR popularized it[^1], at a time when CVS (centrally administered, like Fossil) was still king. [1] = https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug in /finfo not showing Deleted anymore.
On Wed, Jun 13, 2018 at 6:17 PM, Stephan Beal wrote: > On Wed, Jun 13, 2018 at 5:12 PM, Richard Hipp wrote: > >> On 6/13/18, Svyatoslav Mishyn wrote: >> > (Wed, 13 Jun 08:49) Andy Bradford: >> >> I haven't had the time to investigate further, but it seems that >> with >> >> this commit, the /finfo timeline no longer shows when a file >> gets >> >> Deleted: >> >> >> >> http://www.fossil-scm.org/index.html/info/4c268999d5 >> > >> > I've reported it before: >> > https://www.mail-archive.com/fossil-users@lists.fossil-scm.o >> rg/msg27146.html >> >> I'm tied up with a mailing-list infrastructure issue, so if you can >> suggest a patch, that would be helpful. >> > > This is very possibly closely related to the recent json patch which > restored missing files in its timeline: > > http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5 > http://www.fossil-scm.org/index.html/info/4c268999d5 > > Notice how the current UUID is SELECTed in each (previous and current > versions: that section of code in the 2 links above is essentially > mirrored). > Now i'm not so sure: the finfo change removes the subselect (which is working on /json/timeline/checkin) into part of the join, which looks correct to me. The json change switched the join to a left join, though, to pick up the deleted files. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug in /finfo not showing Deleted anymore.
On Wed, Jun 13, 2018 at 5:12 PM, Richard Hipp wrote: > On 6/13/18, Svyatoslav Mishyn wrote: > > (Wed, 13 Jun 08:49) Andy Bradford: > >> I haven't had the time to investigate further, but it seems that with > >> this commit, the /finfo timeline no longer shows when a file gets > >> Deleted: > >> > >> http://www.fossil-scm.org/index.html/info/4c268999d5 > > > > I've reported it before: > > https://www.mail-archive.com/fossil-users@lists.fossil-scm. > org/msg27146.html > > I'm tied up with a mailing-list infrastructure issue, so if you can > suggest a patch, that would be helpful. > This is very possibly closely related to the recent json patch which restored missing files in its timeline: http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5 http://www.fossil-scm.org/index.html/info/4c268999d5 Notice how the current UUID is SELECTed in each (previous and current versions: that section of code in the 2 links above is essentially mirrored). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil binary file size on FreeBSD (amd64)
Try stripping the debug symbols: strip fossil - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Mon, Jun 11, 2018, 07:55 Florian Balmer wrote: > When building Fossil on a recent out-of-the-box FreeBSD (amd64) > virtual machine, the resulting binary file is about 10.1 MB. The > binary files downloaded form [0] are at most 3.8 MB. > > [0] http://pkg.freebsd.org/ > > I have tried various ./configure options, FOSSIL_DYNAMIC_BUILD is > enabled (=1), and TCL seems to be disabled by default (or, is it?). > > Not that it matters (these times are over), but out of curiosity, why > is there such a difference? > > --Florian > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Show time...
On Tue, Jun 5, 2018, 23:19 Stéphane Aulery wrote: > > Barely one day and I have already received this link [1] by Hacker News > RSS feed. > > Maybe you can make your advocacy here. > > [1] https://tutswiki.com/github-alternatives/ Which reminds me: i saw an ad on SourceForge (remember them? The first platform of its kind?) offering git sync from github. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. ___ 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] Repository reports as JSON
On Tue, Jun 5, 2018, 19:03 Offray Vladimir Luna Cárdenas wrote: > Hi, > > I would like to have access to the activity reports information in JSON > format. I know that the json interface is enabled and that is mostly > used by preceding the usual url by the "json/" command (see for example > [1]), but for some reason I can not get any output for several commands > like json/timeline or json/reports in my Fossil repositories. What I'm > missing? Is reports activity available as JSON data? > > [1] http://mutabit.com/repos.fossil/dataweek/json/dir?ci=tip The timeline requires that you tell it which timeline you want, e.g.: http://mutabit.com/repos.fossil/dataweek/json/timeline/checkin For the full json API docs, see: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?usp=drivesdk The reports are not currently available in json. That would not be difficult to implement but i am still on years-long medical leave for severe chronic RSI (from too much programming/documenting) and can't implement it myself :(. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. ___ 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] Rumor: Microsoft has acquired github
On Mon, Jun 4, 2018 at 2:08 AM, Jan Danielsson wrote: > On 2018-06-04 00:35, Stephan Beal wrote: > [---] > > It does kind of make sense: the global leader in creating > > market-leading-yet-unusable software acquires one more piece of > > market-leading-yet-unusable software. > >This appeals to my sense of order. :) > Though, to be fair: github goes to great lengths to make git usable, but with a piece of software so thoroughly misanthropic as git, one can only do so much. We'll supposedly find out "on Monday" whether this rumor is true. It's already Monday in my timezone, but the news outlets don't seem to care about non-US timezones :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Rumor: Microsoft has acquired github
This is currently just a rumor, but a juicy one which should interest some Fossil users: https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors It does kind of make sense: the global leader in creating market-leading-yet-unusable software acquires one more piece of market-leading-yet-unusable software. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON timeline missing deleted files?
On Tue, Mar 13, 2018 at 5:17 PM, Stephan Beal wrote: > suggests that it "looks okay". However, a quick local test also shows that > a removed file is indeed not reported. The first suspect is the related > query: > > https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=323-332 > > i don't recall (it's been far too long) whether or not that catches > deleted files, nor how to make it do so if it doesn't. Anyone wanting to > look into it should start there, though. > i was sent an off-list fix for this today by Edgardo Cruz, which is now in trunk: http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5 Here's an example of the output for deleted files: { "type":"checkin", "uuid":"77b624ba022fbd2c832cc0103e8b0c8fb2610d46", ... "comment":"removed a long-obsolete file.", "files":[{ "name":"include/wh/cwal/cwal_list.h", "parent":"7548ada2f5007797846125812424c5ae49192a1f", "size":0, "state":"removed", "downloadPath":"/raw/include/wh/cwal/cwal_list.h?name=" }] }, -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging attachments
On Thu, May 31, 2018 at 10:51 PM, Eugene MIndrov wrote: > Now, if it was against the implementation then it wouldn't have been > implemented, right? > It was implemented only as a last resort, not for daily use. The very real use case that "needs" to be supported by this feature is that someone commits copyrighted material into someone else's repo. if i were to make a copy of copyrighted ebook and post it as an attachment to someone's fossil wiki, the owner of that wiki _needs_ (for legal reasons) to be able to banish it. Shunning was not one of Fossil's original features - it was added to enable that sort of worst-case scenario. > The main reason I haven't used shun for my purposes is the attachment I > was trying to nuke was taking 90% of the entire repo and shun leaves > shunned artifacts lying around, just adding their SHA into the shun list so > they would be excluded from sync operations. > That's not true: see the very first sentence the documentation of the shun page: "A shunned artifact will not be pushed nor accepted in a pull and the artifact content will be purged from the repository the next time the repository is rebuilt." You simply need to rebuild the repo after shunning. That won't eliminate it from any closes, but it will keep them from re-synching it back to your copy. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Purging attachments
On Thu, May 31, 2018 at 8:03 PM, Миндров Евгений wrote: > Well, now I'm in a situation which has been discussed here many times - I > need to "unmake" certain file attachment from a repo, make it look like it > had never been there. > > I know it goes against the core values of Fossil philosophy and it's akin > to replacing all fossilized trilobite remains in Paleozoic strata with > Oreos so paleontologists would scratch their heads, but anyway. > It's not just against the values, it's against the implementation! There is only one way to nuke data in fossil, and it should only be used as a last-resort option, not in day-to-day maintenance. (i've been using fossil since Christmas of 2007 and have never once used this feature.) fossil help purge provides these warnings: WARNING: This command can potentially destroy historical data and leave your repository in a goofy state. Know what you are doing! Make a backup of your repository before using this command! FURTHER WARNING: This command is a work-in-progress and may yet contain bugs. i.e. don't use that feature ever unless you know for a fact that you absolutely need to. Instead, you "want" (but don't REALLY want) the shun feature. It's only accessible in the UI under the Admin pages (the URI is /shun). You enter the UIDs of the artifacts to shun and it will permanently remove them from your repo. Be sure to read the documentation on that page. PS: you _really_ don't want to remove data from your repo unless someone checked in a password, private SSH key, something copyrighted by someone else, or similar cases. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil delete user
On Tue, May 15, 2018 at 4:59 PM, Peter Vonča <pvo...@gmail.com> wrote: > I understand, how about anonymization then. User "Jane" is deleted. > Replace all references with default user "Anonymous". > Another point to consider is that fossil does not synchronize user information unless it's explicitly told to. e.g. when i pull a copy of the main Fossil SCM repository, it does not copy the users "drh", "jan", etc. etc. Those users exist only as entries in commits (in "manifests", to use the official Fossil terminology). The central repo can add any number of users, but my local copy doesn't know them as users - it only knows them as static strings in commit entries. In short: what you're asking for is, by design, not possible in Fossil. (i don't _think_ it's possible in any SCM, for that matter, but i _know_ that it's not possible in Fossil.) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil delete user
Anonymization is not possible because the user name is part of each commit entry, which means that it affects the hash code of each commit. Changing any data in a commit, including the user name or timestamp, would change the hash, and thereby invalidate every commit which derived from that. Fossil, by design, cannot modify historical data. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Tue, May 15, 2018, 16:59 Peter Vončawrote: > I understand, how about anonymization then. User "Jane" is deleted. > Replace all references with default user "Anonymous". > > > > > On Tue, May 15, 2018 at 12:41 PM, Victor Wagner > wrote: > >> On Tue, 15 May 2018 12:34:07 + >> Peter Vonča wrote: >> >> > Is there a practical reason why users can't be deleted or was it just >> > a design decision? I guess if I stop fossil server I can manually >> > edit the sqlite db and delete from table? >> >> Fossil keeps history forever. How would it do so, if author of some >> commits or wiki edits disappears from the repository completely. >> >> Disable access, revoke privileges, but keep the user in the DB, >> because it has log of his activity. >> -- >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?
On Sat, May 12, 2018 at 5:35 PM, Chris Drexler <ckolum...@ac-drexler.de> wrote: > Does this make sense? At least from a workflow perspective? > Personally, i don't think so ;), but i tend to be admittedly pessimistic when it comes to "oddball setups". How do you expect to sync changes with such users? How do you expect to handle multiple copies of the binary (i.e. multiple copies of the repo) on each user's machine? At some point they'll overwrite one fossil bin with another one, thereby losing any changes they had made to the first. Upgrading the binary should not destroy any associated data, and that's exactly what will happen if all users aren't 100% careful with their copies of the binary. If it's truly static and users only have read-only access to the data, then it's far simpler for them to forego the binary altogether and use http://your-IP to connect to a central copy running on your workstation. "Can of worms" is what immediately comes to mind. An interesting idea, i admit, but "can of worms" trumps "interesting" for me. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?
On Sat, May 12, 2018 at 1:51 PM, Chris Drexler <ckolum...@ac-drexler.de> wrote: > Thoughts? If someone could hint me at the right place within the > fossil code I could also try to provide an implementation. > IMO: every clone would not have that feature, so it would seem (to me) to be of limited use. The only benefit would be that you only have 1 file, instead of 2, to copy to the remote server. (If you build your binary on that server, even that benefit is lost.) If your server is upgraded in a way which becomes incompatible with your fossil binary (incompatible SSL upgrade or (possibly) libc upgrade), you're hosed: the repo is then locked inside a binary file which other fossil binaries cannot read. (i've had hoster-side OS upgrades break my CGI binaries before, though i don't think i've seen it happen to my fossil binaries.) Another point to consider: the binary itself would have to be writable by the web server process, which opens up a potential security hole. In my experience, Apache runs CGI scripts as the account holder (as opposed to some generic 'www' user), and that account holder already has write access to the binary. However, i make my CGI bins read-only, even to myself, "just in case" (because one too many wordpress vulnerabilities have made me paranoid in that regard). It sounds to me like such a feature is tantamount to walking a minefield in which any given mine could leave you unable to access the repository data. Just my opinion, of course. It may very well work out fine for you. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] "malformed database schema"
i suspect that the old sqlite version has something to do with this. Try using "fossil sqlite" instead of sqlite3. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Wed, Apr 11, 2018, 00:09 Jan Danielssonwrote: > Hello, > >I made a fresh clone of https://src.fossil.NetBSD.org/ and it seemed > to run to completion without any problems, but once it's done I can't do > simple queries in it: > > gauss$ sqlite3 netbsd.fossil > > SQLite version 3.8.3.1 2014-02-11 14:52:19 > Enter ".help" for instructions > Enter SQL statements terminated with a ";" > sqlite> .schema > Error: malformed database schema (artifact) - near "(": syntax error > sqlite> select * from config; > Error: malformed database schema (artifact) - near "(": syntax error > >I redid the clone but it ended up in the same state. > >Browsing the source online repo seems to work fine, so I'm assuming > it's a local problem -- but how can it end up in this state? I did no > more than clone it. > > -- > Kind Regards, > Jan Danielsson > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Web interface: "ls -l" list of files?
On Mon, Mar 19, 2018 at 7:30 PM, The Tick <the.t...@gmx.com> wrote: > Is there a was to get a "ls -l" style list of the files in a repository > from the web interface? I see "Tree-View" or "File Ages" but the listing of > "ages" seems to be relative to the last commit time. A related sidebar: fossil doesn't actually store the creation- or modification times of files. The only timestamps it remembers are when changes are made to the repository (a checkin, wiki/ticket edit, new tag applied to a commit, etc.). When fossil tells you the age of a file, it's really showing you the timestamp of the commit which most recently modified that file. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Experimental timeline "View Mode" changes.
Fwiw, i prefer the Classic, with the uid at the start of the message. When it's at the end, the eyes and mouse hand have to look for it in a different place for every entry. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Sat, Mar 17, 2018, 17:02 Richard Hippwrote: > A new "Classic" viewing mode has been added to the timeline. > "Classic" looks the same as "Verbose" did in the previous release. > "Verbose" has now been modified to look the same as "Compact" except > that the check-in details come up expanded. > > I prefer to look at timelines using the new-Verbose. That's why I added > it. > > I'm open to restoring "Verbose" to the old style and then coming up > with a new name for the new-Verbose if anybody has any suggestions. > > The new prototype is installed on the Fossil and SQLite servers if you > want to give it a test run. > >https://fossil-scm.org/fossil/timeline >https://sqlite.org/src/timeline > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON timeline missing deleted files?
On Tue, Mar 13, 2018 at 10:09 AM, Stephan Beal <sgb...@googlemail.com> wrote: > On Tue, Mar 13, 2018 at 12:17 AM, João Batista <jmn.bati...@gmail.com> > wrote: > >> With fossil 2.5, it seems that "fossil json timeline checkin" does not >> show deleted files in a checkin, but "fossil timeline -t ci" does: >> ...So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-) >> > > i _think_ what happened here is that at the time (late 2011) is that the > timeline page didn't list deleted files, and the json timeline simply > adopted that behaviour. i may be misremembering, but i can't conceive of > another reason i may have left that out. ... > More details... The JSON docs: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view Say that each file's state is reported as one of the strings (modified, added, removed). A quick glance through the related code: https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=353-354 and https://www.fossil-scm.org/index.html/artifact/6530c919e6671cbe?ln=282-288 suggests that it "looks okay". However, a quick local test also shows that a removed file is indeed not reported. The first suspect is the related query: https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=323-332 i don't recall (it's been far too long) whether or not that catches deleted files, nor how to make it do so if it doesn't. Anyone wanting to look into it should start there, though. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON timeline missing deleted files?
On Tue, Mar 13, 2018 at 12:17 AM, João Batista <jmn.bati...@gmail.com> wrote: > With fossil 2.5, it seems that "fossil json timeline checkin" does not > show deleted files in a checkin, but "fossil timeline -t ci" does: > ...So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-) > i _think_ what happened here is that at the time (late 2011) is that the timeline page didn't list deleted files, and the json timeline simply adopted that behaviour. i may be misremembering, but i can't conceive of another reason i may have left that out. Unfortunately, i'm still on long-term medical leave for a severe case of RSI in both arms, so my typing is limited and my programming even more so, so i can't personally commit to correcting this for the foreseeable future. (That's not to say that someone else couldn't do it, though!) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON timeline missing deleted files?
That sounds like an omission, but i don't recall off hand (that code is about 5 years old now). i will take a look at it tomorrow (Central Euro Time). - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Tue, Mar 13, 2018, 00:18 João Batistawrote: > Hello all, > > With fossil 2.5, it seems that "fossil json timeline checkin" does not > show deleted files in a checkin, but "fossil timeline -t ci" does: > > # fossil version -v > This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC > Compiled on Feb 28 2018 23:03:00 using gcc-5.4.0 20160609 (64-bit) > Schema version 2015-01-24 > zlib 1.2.8, loaded 1.2.8 > hardened-SHA1 by Marc Stevens and Dan Shumow > SSL (OpenSSL 1.0.2g 1 Mar 2016) > JSON (API 20120713) > UNICODE_COMMAND_LINE > FOSSIL_DYNAMIC_BUILD > SQLite 3.22.0 2018-01-22 18:45:57 0c55d17973 > SQLITE_DEFAULT_FILE_FORMAT=4 > SQLITE_DEFAULT_WAL_SYNCHRONOUS=1 > SQLITE_ENABLE_DBSTAT_VTAB > SQLITE_ENABLE_FTS3_PARENTHESIS > SQLITE_ENABLE_FTS4 > SQLITE_ENABLE_FTS5 > SQLITE_ENABLE_JSON1 > SQLITE_ENABLE_LOCKING_STYLE=0 > SQLITE_ENABLE_STMTVTAB > SQLITE_LIKE_DOESNT_MATCH_BLOBS > SQLITE_MAX_EXPR_DEPTH=0 > SQLITE_OMIT_DECLTYPE > SQLITE_OMIT_DEPRECATED > SQLITE_OMIT_GET_TABLE > SQLITE_OMIT_LOAD_EXTENSION > SQLITE_OMIT_PROGRESS_CALLBACK > SQLITE_OMIT_SHARED_CACHE > SQLITE_THREADSAFE=0 > SQLITE_USE_ALLOCA > # fossil timeline 0d11ea056b -t ci -v | grep www >EDITED www/changes.wiki >EDITED www/env-opts.md >EDITED www/index.wiki >DELETED www/mkdownload.tcl >EDITED www/server.wiki > # fossil json timeline checkin 0d11ea056b -v -n 1 | grep '"name":' | grep > www > "name":"www/changes.wiki", > "name":"www/env-opts.md", > "name":"www/index.wiki", > "name":"www/server.wiki", > # > > > So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-) > > Regards, > J Batista. > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Repo extension in "fossil cgi" when used with "directory:"
On Wed, Feb 21, 2018 at 6:01 PM, Richard Hipp <d...@sqlite.org> wrote: > I tried to do this. It turns out to be non-trivial. Can you not > simply rename your repositories to use the standard ".fossil" suffix? > i'm not sure, off-hand, whether symlinks (or hard links) are a problem via-a-vis sqlite or 'fossil rebuild', but either symlinks or hard links might be another option, simply aliasing the .fsl files. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Windows GUI that allows diff between two, revisions?
On Thu, Feb 15, 2018 at 10:43 PM, Gilles <codecompl...@free.fr> wrote: > Alternatively: As a work-around, what about offering an easy-to-parse > output from the EXE ? > > For instance, I'd like to find all the release versions for a given file, > so as to display the list and let the user pick two to perform a diff: > Current > C:\>fossil finfo myfile.c > History of myfile.c > fossil json finfo myfile.c e.g. [stephan@lapdog:~/fossil/fossil]$ f json finfo BUILD.txt | head -20 { "fossil":"6b41a7e803348a9247818a66c9b968a9fd8e5d3408cecdad905c08dc018a", "timestamp":1518732431, "command":"finfo", "procTimeUs":4000, "procTimeMs":4, "warnings":[{ "code":1, "text":"Achtung: the output of the finfo command is up for change." }], "payload":{ "name":"BUILD.txt", "checkins":[ { "checkin":"06ffd8009ff257ded9f98e179fd52513081ddcf2", "uuid":"976db410b019ec100c95da8aa977d6209fee9a4e", "timestamp":1428028595, "user":"mistachkin", "comment":"Merge updates from trunk.", "size":2704, [stephan@lapdog:~/fossil/fossil]$ -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Windows GUI that allows diff between two, revisions?
On Thu, Feb 15, 2018 at 3:48 PM, Gilles <codecompl...@free.fr> wrote: > On 15/02/2018 15:17, Richard Hipp wrote: > >> ...There was a project to rewrite Fossil as a DLL, but there has been no >> recent progress on that. >> > Too bad. > That's my fault. Severe RSI has left me on medical leave for most of the past 3 years (with no end in sight), which has effectively removed me from the programming scene. While libfossil was quite far along (aside from networking support, it had, at the library level, essentially all of the required features)), the SHA1 "attack" and subsequent reworking on fossil have left libfossil requiring a non-trivial amount of rework to catch up, and i'm physically unable to do it :/. If someone would like to take it over, the code is here: http://fossil.wanderinghorse.net/r/libfossil -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug Report: Fossil 2.3 runs out of Memory During Check-in
On Sat, Jan 27, 2018 at 8:20 AM, Martin Vahi <martin.v...@softf1.com> wrote: > About 5GiB of it is the Fossil repository file and > about 17GiB of it is a tar-file with about 140k files that > the test tries to insert to the fossil repository. > i'm gonna go ahead and say it because every else is thinking it: Short answer: Nope. The longer answer: As Warren said before, Fossil is going to need some multiplier of that size in memory. Simply reading that file for insertion into the db requires 1x its size. The sqlite3 bind process is, i see now, already optimized as far as it can be to eliminate yet another in-memory copy of that blob: http://fossil-scm.org/fossil/artifact/6d07632054b709a5?ln=350-351 Your system is very likely failing on that first allocation of 17GiB. If it's not, then it's going to fail further down the line when... a) you use the 'zip' or 'tar' commands, which build their archives in memory. If it doesn't fail here then it will fail when... b) you try to commit a change to that file. In that case, fossil needs 2-3x that amount of memory (in separate allocations) in order to be able to create and apply the delta: 37.x-51GiB of RAM _just for that one file_. That's excluding any other memory costs it has. Fossil is intended for managing source code, not... whatever it is that you believe a 17GiB blob needs to be doing in a source control system (in a piece of hardware containing only a small fraction that amount of memory, no less). Barring major architectural upheaval (one step of which would be reimplementing the delta generator and applicator to stream their i/o, rather than working in-memory), your use case simply is not realistic in fossil. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 413 Request Entity Too Large
On Thu, Jan 11, 2018 at 2:43 PM, Dingyuan Wang <gumb...@aosc.io> wrote: > When I committed a large blob, How large? Fossil requires a great deal of RAM to process diffs of blobs: 1) the memory for version 1 2) the memory for version 2 3) the memory for the diff of v1 and v2. e.g. if you are trying to commit a 5-byte change to a 1GB blob, fossil needs just over 2GB of memory to commit that. I can't sync with my server, which uses > nginx for reverse proxy. > "server says: 413 Request Entity Too Large" i can find "413" nowhere in fossil's source code except in unrelated Unicode bits. It seems like this message is coming from your nginx. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Errors in current trunk (24c2b99d) related to TIMESPEC
On Tue, Jan 9, 2018 at 9:09 PM, The Tick <the.t...@gmx.com> wrote: > src/cson_amalgamation.c: In function 'cson_str_to_json': > src/cson_amalgamation.c:3888:51: warning: '%04x' directive writing 4 > bytes into a region of size between 3 and 5 [-Wformat-overflow=] >rc = sprintf(ubuf, "\\u%04x\\u%04x", > ^~~~ > src/cson_amalgamation.c:3888:40: note: directive argument in the range > [56320, 57343] >rc = sprintf(ubuf, "\\u%04x\\u%04x", > ^~~~ > src/cson_amalgamation.c:3888:24: note: 'sprintf' output between 13 and > 15 bytes into a destination of size 13 >rc = sprintf(ubuf, "\\u%04x\\u%04x", >~~~^ > (0xd800 | (ch>>10)), > > (0xdc00 | (ch & 0x3ff))); > > That buffer has been increased to 20 bytes. Please try with the latest trunk. Thank you for your persistence! http://fossil-scm.org/fossil/info/e508424e7d7863e1 -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Errors in current trunk (24c2b99d) related to TIMESPEC
i will take a look at the cson warnings - that fike is generated from an upstream tree. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Jan 9, 2018 21:17, "jungle Boogie"wrote: > On 9 January 2018 at 06:32, Richard Hipp wrote: > > A new version of Fossil is now on trunk. > > (https://www.fossil-scm.org/fossil/info/9a33a240a2101ede) Please try > > again to build on every platform you have at hand, but especially all > > variations of MSVC and MinGW, and let me know whether or not you run > > into build issues. > > > > I don't see any build errors when using MS Visual Studio 2017, > v15.0.26730.16. > I just performed a fossil up trunk and the make flags. > > > > -- > > D. Richard Hipp > > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil-users Digest, Vol 120, Issue 2
(this time back to the list) On Tue, Jan 2, 2018 at 3:43 AM, Andy Bradford <amb-fos...@bradfords.org> wrote: > Thus said Stephan Beal on Tue, 02 Jan 2018 03:07:20 +0100: > > > That will still strip any newlines from his input, though, because > > that's how $(...) works. > > It actually only strips the trailing newline. Any newlines in the middle > of the file are fine. That's not what i'm seeing: [stephan@host:~]$ echo -e "1\n2\n3" 1 2 3 [stephan@host:~]$ echo $(echo -e "1\n2\n3") 1 2 3 -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil-users Digest, Vol 120, Issue 2
On Tue, Jan 2, 2018 at 2:25 AM, Ron W <ronw.m...@gmail.com> wrote: > Try splitting the long text file into 2 or more smaller files, then add > the ticket using the first file. Then you can append to the comment: > >$ fossil ticket change TICKETUUID +comment "$(cat content_next)" > That will still strip any newlines from his input, though, because that's how $(...) works. To get the comment text imported verbatim, i suspect that the ticket command needs to support a -M FILENAME option to import a comment, like checkin does. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mimetype of a ticket with specified mimetype
On Mon, Jan 1, 2018 at 1:58 PM, Sergey Bronnikov <este...@gmail.com> wrote: > $ fossil ticket add title "title" comment "$(cat bugs-example1)" mimetype > "text/plain" > > When I open this ticket in a Web UI it shows as "formatted" and all lines > are stick together. Content view becomes fine with switch to 'plaintext' > mode above ticket. > The question is: why fossil shows me formatted text when I specified it as > "text/plain"? > Running a command through $(...) strips any newlines from the output, which is likely mangling your comment text. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Import --svn "internal error: out of memory"
On Wed, Dec 27, 2017 at 12:44 PM, Olivier Mascia <o...@integral.be> wrote: > Being "rookie" with Fossil, I'm starting some tests to migrate some of our > subversion repositories to Fossil and have a better test bed to learn > fossil before eventually deciding on a switch. > To quote the Oracle: "[Because] You didn't come here to make the choice, you've already made it. You're here to try to understand why you made it." Welcome aboard! :) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil hack: quickly finding the first checkin via the web UI
i sometimes want to find out how old a given 3rd-party repo is, and paging through the timeline is a tedious way to do it. It can be done more quickly by drilling down through the /reports (by year, selecting the first year, then the first week-of-year). What i didn't know, until today, is that it's possible to use fossil's "rid:#" artifact ID alias with the /info page, e.g.: https://fossil-scm.org/fossil/info/rid:1 RID #1 is always the first artifact ever stored in the fossil db, which is (historically, at least) the empty initial checkin. i'm not sure that that always applies after a rebuild/reconstruct, but it works on all the repos i've tried so far. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tangent vs. wyoung on recent commti
Fwiw, i agree completely, plus suspect (without knowing for certain) that including a user's IP (and thus, indirectly, location) in the permanent record _might_ run afoul of privacy laws in some jurisdictions. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Dec 18, 2017 10:12, "Jan Nijtmans"wrote: > 2017-12-18 5:58 GMT+01:00 Ron W: > > All I'm suggesting is that the information already being put in the > > "rcvfrom" table (that DRH mentioned) also be saved as tags to the commits > > they refer to. Therefore, the tags will have the same meaning as the > entries > > in the existing "rcvfrom" table. > > Well, I don't think this is even possible, neither does it help > accomplishing > what you want. Tags can easily forged as well. Another problem: tags, when > created in one repository will later synchronized to other repositories > (even back to the original one), so I'm really not sure what the > value of the information in it really is . I wouldn't go this path. > > My suggestion would be: try to come up with a patch, which does what > you suggest. I don't think it would help anything, but feel free to prove > me wrong! > > Thanks! > Jan Nijtmans > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tangent vs. wyoung on recent commti
On Thu, Dec 14, 2017 at 9:38 PM, Ron W <ronw.m...@gmail.com> wrote: > Local, command line usage seems to grant the command line user full > permissions as long as the user has RW access to the repo file, itself. > > Right now, I can't test this to confirm this behavior. > That's correct: all CLI commands simply bypass (i.e. don't check) permissions. Only client/server commands check permissions. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to share a fossil repo using static http (without the cgi)?
In short, no. To be able to clone, fossil needs a server process of some sort, which means either CGI or a the built-in standalone http server. It can use SSH, but that uses fossil's built-in server to do the real work. PS: the db does not store raw user passwords, but does store hashes of those passwords. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Dec 12, 2017 20:55, "Juan Francisco Cantero Hurtado"wrote: > Something like: > > https://git-scm.com/book/en/v1/Git-Internals-Transfer-Protoc > ols#The-Dumb-Protocol > > https://www.mercurial-scm.org/wiki/StaticHTTP > > IIUC, the .fossil files include the users passwords and I don't know if > those include more private info. So, I can't just share directly the file. > > Let me give you an example, so it's more clear. I want share a fossil repo > using a static http server, without the cgi. And I want share only the > "code part" without the wiki or the issues. The user could clone the repo > and pull regularly the changes. Can I do something like that with fossil?. > > Cheers. > > > -- > Juan Francisco Cantero Hurtado http://juanfra.info > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Older fossil archives are not rebuild-able
On Tue, Dec 12, 2017 at 6:57 PM, J Knight <j...@j2mfk.com> wrote: > Hello. I have some older fossil archives that report: > > > > SQLITE_ERROR: table config has no column named mtime > > fossil: table config has no column named mtime: {REPLACE INTO > config(name,value,mtime) VALUES('hash-policy',1,now())} > > > > issuing a ‘rebuild’ and a ‘rebuild –force’ gives the same error. Is there > some way to bring these up to date or somehow migrate? > i'm not 100% certain that this will do the job, but it's worth a try... See: [stephan@host:~]$ f help decon Usage f deconstruct ?OPTIONS? DESTINATION This command exports all artifacts of a given repository and writes all artifacts to the file system. The DESTINATION directory will be populated with subdirectories AA and files AA/B.., where AAB.. is the 40+ character artifact ID, AA the first 2 characters. If -L|--prefixlength is given, the length (default 2) of the directory prefix can be set to 0,1,..,9 characters. Options: -R|--repository REPOSITORY deconstruct given REPOSITORY -L|--prefixlength N set the length of the names of the DESTINATION subdirectories to N --private Include private artifacts. See also: rebuild, reconstruct [stephan@host:~]$ f help recon Usage: f reconstruct FILENAME DIRECTORY This command studies the artifacts (files) in DIRECTORY and reconstructs the fossil record from them. It places the new fossil repository in FILENAME. Subdirectories are read, files with leading '.' in the filename are ignored. See also: deconstruct, rebuil So... (untested)... fossil decon -R repo.file ~/tmp/xxx Then: fossil recon repo-new.file ~/tmp/xxx -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Lots of web interface changes
On Wed, Dec 6, 2017 at 10:59 PM, Richard Hipp <d...@sqlite.org> wrote: > On 12/6/17, Stephan Beal <sgb...@googlemail.com> wrote: > > On Wed, Dec 6, 2017 at 8:33 PM, Richard Hipp <d...@sqlite.org> wrote: > > > >> know.) Are you still having the same problem with the latest > >> code, even after hitting multiple "Reloads"? > >> > > > > Just tested: no :) > > I just brought up chrome here on my desktop and on a Win7 laptop and > they both seems to be working fine. Can you give me more information > on how to repro the problem? Sorry, i could have been more explicit: no, i don't have the problem anymore - it may have been a transient problem. :) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Lots of web interface changes
On Wed, Dec 6, 2017 at 8:33 PM, Richard Hipp <d...@sqlite.org> wrote: > know.) Are you still having the same problem with the latest > code, even after hitting multiple "Reloads"? > Just tested: no :) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Lots of web interface changes
On Wed, Dec 6, 2017 at 8:22 PM, Richard Hipp <d...@sqlite.org> wrote: > There have been lots of changes (hopefully, "improvements") to the web > interface of Fossil over the past few days. If you have not be > following the developments, I encourage you to visit a few of the main > sites running the latest code and let me know what you think. Your > suggestions and comments are very important. > FYI: i noticed two days ago that on my tablet (Chrome browser) that the various timeline links all point to the honeypot page. It seems the bot detection got unduly stringent (i know that's an ongoing war). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Trolling GitHub for ideas
On Mon, Nov 27, 2017 at 10:50 AM, Javier Guerra Giraldez <jav...@guerrag.com > wrote: > ideally, on any diff view (a commit, a diff between two versions, a > merge preview), i'd like to add comments right there, interleaved with > the code. optionally added to a ticket too; so that opening the ticket > would show all related comments, each with a short view of the code > and a link to the full context. > GoogleCode (or one of the similar platforms) had the ability to comment on lines of files/diffs, and i have missed that feature at least twice in fossil. i.e. +1 -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More timeline changes
On Sat, Nov 25, 2017 at 11:06 PM, Tony Papadimitriou <to...@acm.org> wrote: > The idea looks very good to me. But the ellipses are indeed barely > visible. > How about replacing ... with [*] as a generic (foot)note mark? > LOL! i didn't even notice that the ellipsis were there. i recommend doing away with them entirely, an simply making "click a timeline entry to expand its details" a new documented feature. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More timeline changes
On Sat, Nov 25, 2017 at 2:47 PM, Richard Hipp <d...@sqlite.org> wrote: > In the latest code on https://www.fossil-scm.org/fossil/timeline and > at https://sqlite.org/srcx/timeline has a "Declutter" button on the > sub-menu bar to simplify the screen. In the simplified timeline, > there is a "Details" button to get all the details back again. > i was about to suggest that clicking on a single entry declutter only that entry, but it seems you already did that :). (2) Decluttered should be the default. Currently Details is the > default. I spent a lot of time experimenting last night, and what I > found myself doing every time I encountered a timeline was immediately > pressing the "Declutter" button to get a high-level overview of the > graph, then clicking on "Details" if I wanted to see more. From that > experience, I think coming up in Decluttered mode would be a much > better approach. > "This should be the default" was my first impression. > ...decluttered mode (showing only the check-in comment for each entry) > but with ellipses or some other small icon at the end of each comment > that you can click on to expand the details. > i like the way it works now, that you simply click anywhere on the row. Granted, it's possibly not intuitive without some visual indicator to click on ("..."), but it's visually elegant. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Interface improvement ideas from GitHub
A short sidebar for those unfamiliar with this particular quirk of JS: On Sat, Nov 25, 2017 at 3:49 PM, David Mason <dma...@ryerson.ca> wrote: > node.setAttribute('title','Click to '+(expand || 'expand')); > In JS the || operators evaluates to the first value of its left/right sides which itself evaluates to true in a "boolean context". i.e.: 2 || 3 in almost every other language that evaluates to true, whereas in JS it evaluates to 2. Likewise (0 || 7) evaluates to 7. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Clone a repo served by a winsrv service
On Fri, Nov 24, 2017 at 1:00 AM, Stéphane Aulery <lk...@free.fr> wrote: > Hello, > > Yet an error form winsrv feature. > > I try to clone a new repo and get this error : > > $ fossil clone -v http://fossil/eulalia/ eulalia.fossil > Bytes Cards Artifacts Deltas > waiting for server... > getaddrinfo() fails: Hôte inconnu. > It cannot resolve the name "fossil" a your computer. What does "ping fossil" (from a "cmd" window) say? -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] unexpected tcl error dialog via diff -tk
On Thu, Nov 16, 2017 at 3:45 AM, Richard Hipp <d...@sqlite.org> wrote: > I also fixed a couple other key bindings while I was at it. Control-q > now exits. :-D I noticed the pressing Escape twice also exits. (That is > not new, I just hadn't noticed it before.) > i saw a comment to that effect a week or two ago but it didn't do anything on the version i had. After an update, both ctrl-q and escesc close it (and both are equally finger-friendly). Thank you! -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] unexpected tcl error dialog via diff -tk
Minor "cosmetic bug" report... fossil diff -tk Once the tcl window starts up, simply tap ENTER (i did it by accident). That pops up a dialog saying: Error: bad window name/identifier "bb.files" The Details button says: bad window name/identifier "bb.files" bad window name/identifier "bb.files" while executing "event generate bb.files <1>" (command bound to event) It does not happen if ENTER is pressed in the Search field. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Could not find a valid check-in for RID xxxx. Possible checkout/repo mismatch.
On Wed, Nov 15, 2017 at 10:35 AM, Stefan Bellon <sbel...@sbellon.de> wrote: > Hi Fossil Users, > > we are getting the following message when attempting a commit: > > Could not find a valid check-in for RID . > Possible checkout/repo mismatch. > > What could be the reason for that? > RIDs are internal numbers which can be different for any given copy of a repository. This error mostly likely means that someone replaced an opened repository with a copy from a different source. For example, if you cloned it, then checked it out, then replaced the cloned copy of the repo from a backup. In that case, the checkout RIDs might not match those of the repo file. i recommend trying the following from the checkout directory: 1) fossil close It will warn about uncommitted changes. Tap "Y" to accept it (you won't lose any data except fossil's "stash" and "undo"). 2) fossil open /path/to/repo.fossil --keep that will open the repo again, keeping any local changes. That "might" solve the problem. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [Nmh-workers] Merging Source Files with git. (fwd)
On Tue, Nov 14, 2017 at 4:26 PM, Warren Young <war...@etr-usa.com> wrote: > https://tangentsoft.com/pidp8i/finfo?name=libexec/mkos8 Don't take this the wrong way, but that is a mighty fine skin you have, sir. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] "snapshot" alias...
Apropos nothing at all, i wanted to share a fossil shell alias which i have often found useful: alias fsnap='fossil stash snapshot -m "snapshot @ $(date)" && echo "snapshot created"' (Remember to replace $(date) with `date` if you're using an older-style shell or if you simply prefer backticks.) -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON API
On Sun, Nov 12, 2017 at 1:12 PM, <bytevolc...@safe-mail.net> wrote: > Good day to you all, > > I have been trying to find up-to-date information about the JSON API > built into Fossil. Is there any plans on moving forward with this? i'm the original developer of the JSON API, but a severe, long-term case of RSI (since Dec. 2014) has forced me to retire from my open source work (except for occasional tiny patches), thus i don't personally work on it any more. It's unclear if/when my damaged elbow nerves will ever recover, so i can't make any code-related commitments (my left elbow is still not fully recovered after an OP last May, and i've got a second operation planned for early 2018 to try to alleviate the problem in the right elbow). That's not to say that the JSON API is off-limits to other developers! i would love to see someone take it over and actively work on it. > The latest information I could find is a link to a document on Google > Docs in a mail dated back in 2013 or so, and I cannot tell when the > document was last updated. The last time it was mentioned on the > official fossil-users mailing list was in March 2017 > (https://www.mail-archive.com/fossil-users@lists.fossil-scm. > org/msg24857.html) > but simply mentioned the same Google Docs document: > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2q > NUkBEgiUvoqFN4/view Those are still the current/complete docs. If someone has mutated the JSON code such that it no longer matches those docs, i'm not aware of it. > Has this API been abandoned? Not abandoned, just not currently actively developed. > It seems like a nice feature if you > want to develop a custom UI or application that uses Fossil as a > back-end, such as a full-blown wiki, for example. > That's exactly what i use the JSON API for. e.g.: http://fossil.wanderinghorse.net/wikis/cson that uses a custom front-end to server/manage wiki content from/in a fossil repo. It uses client-side rendering using the GoogleCode wiki format, rather than Fossil's built-in one. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] feature request: diff -tk: 'q' to quit
Lol - i never even noticed that there was a search box in the diff view. i'd be just as happy with ctrl-q - anything which is left-hand friendly. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Nov 12, 2017 01:06, <fos...@pointsman.de> wrote: > > Stephan Beal writes: > > Sometime in the far past, tapping 'q' (or maybe it was 'x') in the diff > -tk > > widget used to exit that widget. Nowadays one has to click the "Quit" > > button or tap Alt-F4 (a really finger-clumsy holdover from early Windows > > versions). > > It was 'q'. It was removed by > http://fossil-scm.org/index.html/info/f6d9583173cbd6d2 > > It missed it so much that I use a for that patched fossil. > > > Can we please, please, please get the 'q'==>quit functionality back? It > > sounds like a trivial thing to add, but the tcl code is all Greek to me > :/. > > I second that plea. > > I still use the proposed patch from > > https://www.mail-archive.com/fossil-users@lists.fossil-scm. > org/msg24885.html > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] feature request: diff -tk: 'q' to quit
Sometime in the far past, tapping 'q' (or maybe it was 'x') in the diff -tk widget used to exit that widget. Nowadays one has to click the "Quit" button or tap Alt-F4 (a really finger-clumsy holdover from early Windows versions). Can we please, please, please get the 'q'==>quit functionality back? It sounds like a trivial thing to add, but the tcl code is all Greek to me :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Main repository moved from http to https?
On Tue, Nov 7, 2017 at 11:25 AM, Stefan Bellon <sbel...@sbellon.de> wrote: > Dear Fossil users, > > until recently a fossil remote of http://www.fossil-scm.org/ worked, > but now I get > > cannot connect to host www.fossil-scm.org:80 > fwiw, that also happened to me when i typed "sqlite.org/src" into my browser's URL bar today. Only after saying to myself "wha!?!?" and googling did i get the https link and land on the site (at which point i realized that https was the missing puzzle piece). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] bug(?) in glob handling on exact match?
On Thu, Nov 2, 2017 at 4:53 PM, Francis Daly <fran...@daoine.org> wrote: > From the doc page above: > > Pattern Effect > README Matches only a file named README in the root of the tree. It does > not match a file named src/README because it does not include any > characters that consume (and match) the src/ part. > Fair enough. i only checked the 'f set' help text before posting. Thank you! -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] bug(?) in glob handling on exact match?
i'm not sure if this is a bug or not, but it looks like one... i'm trying to import an ancient SVN repo into fossil: # cat .fossil-settings/crlf-glob makefile # f com -m 'initial import from sourceforge.net/p/toc (20090708).' ./original/examples/ch04-extent/makefile contains CR/LF line endings. Use --no-warnings or the "crlf-glob" setting to disable this warning. Commit anyhow (a=all/c=convert/y/N)? ^C note that 'makefile' is an exact match for the crlf-glob entry. If i modify crlf-glob to: */makefile then it works just fine. i rather expected 'makefile' to work just like a normal glob and match any matching filename. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CI thinks check-in is empty
It sounds like code.exe is starting up in "the background" (for lack of a better word) and returns control to the caller before code.exe exits. What happens when you start code.exe from the console? If the console continues accepting input after code.exe has started, then it's incompatible with fossil in this reg6, as fossil expects the call to return only after the editor has quit. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Nov 1, 2017 00:24, "jungle Boogie"wrote: > Hi All, > > I would like this to be my editor on Windows: > "C:\Program Files\Microsoft VS Code\Code.exe" > > I was able to set it up as my editor: > >fossil set editor > editor (local) "C:\Program Files\Microsoft VS Code\Code.exe" > > I wanted to commit a change: > >fossil ci > > This opened VS Code and generated a text file in my project directory. > I typed my message, saved and closed. Fossil had moved on long ago and > assumed my check-in was empty and asked if I wanted to proceed: > > >fossil ci > Autosync: http://localhost:8080 > Round-trips: 1 Artifacts sent: 0 received: 0 > Pull done, sent: 306 received: 772 ip: 127.0.0.1 > "C:\Program Files\Microsoft VS Code\Code.exe" "./ci-comment-636BBE9D36FF. > txt" > > empty check-in comment. continue (y/N)? n > > Fossil opened VS Code in a couple seconds and I started typing my message. > > Is it likely VS code is too slow for fossil before it thinks there's > an empty check-in? > > What's an editor Widows folks use? I have gvim installed, so I can > switch to that familiar editor if you folks think VS Code is just a > bit too slow for fossil. > > Thanks! > > -- > --- > inum: 883510009027723 > sip: jungleboo...@sip2sip.info > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug Report: Cloning with --private Fails
An unrelated tip: with that url, anyone can download your whole repo via your web server, bypassing fossil's login. It's far safer to store your repo db in a path unreachable by your web server so that the db can only be accessed via fossil. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Oct 23, 2017 10:27, "Martin Vahi"wrote: > > It doesn't even prompt for a password. > Both, client side and server side, Fossil binaries > are of version 2.3 > > ---citation--start- > time nice -n18 fossil clone --unversioned --private --admin-user > martin_vahi > https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/ > ./repository_storage.fossil > Round-trips: 2 Artifacts sent: 0 received: 238 > Error: not authorized to sync private content > Round-trips: 2 Artifacts sent: 0 received: 238 > Clone done, sent: 683 received: 65921513 ip: 185.7.252.74 > server returned an error - clone aborted > > real1m31.898s > user0m5.254s > sys 0m2.647s > ts2@linux-0fiz:~/Projektid/progremise_infrastruktuur/andmevahetustarkvara/ > rakendusvõrgud/silktorrent/publitseerimishoidla$ > ---citation--end > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] An idea about mutable history*
On Sat, Oct 21, 2017 at 10:51 AM, Stanislav Paskalev <ksh...@gmail.com> wrote: > I would imagine an implementation where by default the presentation > DAG is the same as the raw one and having additional commands (that > appear in the raw one as commits) to alter the presentation view. > > Do you think that this approach is proper and feasible ? > IMO it sounds both interesting and feasible (but not a small amount of work). It's essentially a timeline view using supplemental (human-edited) inheritance/grouping metadata. Because the timeline is the single most complex piece of UI-centric code, though, i would recommend using a different URI for such a feature, /timeline/alt or /alternate-reality. It would obviously need new commands to manipulate/maintain the "adopted" family groupings of artifacts. One important question which would need to be answered early on is how to store this metadata. In a new Artifact type (so that it's permanent and immutable) or in a plain DB table (which isn't "as permanent" as an Artifact, but it may not need to be). If it's in a new Artifact type, then it would obviously (because of its pseudo-mutable nature) require a way to update it for purposes of the alternate timeline (e.g. "newest update wins"). Anyway... There are lots of questions to pose and answer, but i think the idea has merit. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Minor typo in last commit
On Thu, Oct 19, 2017 at 10:39 AM, Johan Kuuse <jo...@kuu.se> wrote: > - * web\_args -- _Current weg page arguments._ > + * web\_args -- _Current web page arguments._ > Fixed! Thanks for the report. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink
On Wed, Oct 18, 2017 at 4:27 PM, Warren Youngwrote: > If you have any Ajax calls back to the remote fossil executable and they > ship back
Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink
On Wed, Oct 18, 2017 at 3:04 PM, Richard Hippwrote: > as
Re: [fossil-users] Fossil README symlink
On Wed, Oct 18, 2017 at 11:44 AM, Warren Young <war...@etr-usa.com> wrote: > A great many of the old concerns about the security problems with > Javascript have gone away through various efforts, and atop that, the vast > majority of web sites and web apps now require JavaScript. > Including *cough* github *cough*. It loads about 92k of JS on its home page, and then sends of 2 XHR requests after that. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merge question
On Mon, Sep 25, 2017 at 5:32 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: > whatever was going on. Might want to explicitly turn on more warnings > like -Wunused or -Wall or even -Wextra to help spot these types of issues.) > Sidebar: i tried -Wall with fossil years ago but it didn't like sqlite3's use of "long long", which isn't C89 (i'm not even sure it's C99, but it's apparently supported by all compilers). -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Empty file constantly being deleted
On Fri, Sep 8, 2017 at 3:49 PM, Thomas <tho...@dateiliste.com> wrote: > > How do I mark a file as deleted? https://www.fossil-scm.org/index.html/help/rm -- ----- stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Is there a way to specify paths relative to checkout's root?
On Thu, Sep 7, 2017 at 7:20 PM, Tony Papadimitriou <to...@acm.org> wrote: > OK, thanks. > > But, what would be wrong with using / which is closer semantically, and > compatible to both Linux and Windows path syntax? > Just to avoid potential ambiguity and user confusion (because Unix users expect / to mean something very specific, having nothing at all to do with fossil). My concern is that using / as the prefix would eventually step on someone's toes, either confusing them or downright breaking some semantics (though i admittedly don't have an example which would break something). svn uses the ^ prefix as an alias for SVNROOT, so maybe that would be a good choice. i don't recall off hand whether ^ is a legal filename character for Fossil. The : would be a character which cannot possibly be used in fossil filenames names up to this point, making it safe for such usage. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Is there a way to specify paths relative to checkout's root?
There's not currently, and if someone wants to implement it i would suggest : as a prefix, since fossil does not allow : in file names (for Windows compatibility). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Sep 7, 2017 18:43, "Tony Papadimitriou"wrote: > For example, assuming a checkout tree like this: > > lib/file > a/b/c/d/e/f/g/h/j/file > > and while inside the j subdirectory, I want to refer to lib/file by doing > something like: > > fossil tim –p /lib/file > > instead of > > fossil tim –p ../../../../../../../../lib/file > > (and not sure if I got the number of ../ right, see the problem?) > > Similar to how one uses ~ to refer to home path in Linux, although I’m > interested for this to work in Windows also. > > I tried both ~ and / with no success. > (I guess / would be the obvious way to do this as it’s the checkout’s > logical root.) > > Is there a way to do this? > > Thanks. > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Empty file constantly being deleted
On Thu, Sep 7, 2017 at 12:29 AM, Thomas <tho...@dateiliste.com> wrote: > Hello, > > I got an issue with an empty file that's constantly being deleted whenever > I run the checkin script after another contributor checked in using the > same script. > > The script does: > fossil addremove --dotfiles > fossil update --force-missing > fossil configuration pull shun > fossil commit --allow-empty --allow-conflict --hash > > There's several files with a filesize of 0. They shouldn't go in the > repository, and actually they don't. They're used as flags each contributor > can create to get rid of some messages within some to Fossil unrelated > scripts. > i'm speculating, based on the fact that you're pulling "shun" info, that you once shunned one of those files. ALL empty files have the same hash code, so if you shunned one of them, you've shunned them all. -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Initial empty checkin?
Fwiw: My recollection and opinion are the same. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity, typos, and top-posting. On Aug 17, 2017 07:35, "Andy Bradford"wrote: > Thus said Andy Goth on Wed, 16 Aug 2017 10:47:56 -0500: > > > What of this old thread? Are the issues it discusses still pertinent, > > or have they been resolved? > > I believe all the relevant issues were actually resolved, however, I > think it was still unfavorable given the time that was available for > testing the changes before release. > > Personally, I would be in favor of retaining the old behavior by > default, but allowing a command line option to ``fossil init'' that > would initialize a new repository without it. > > Andy > -- > TAI64 timestamp: 400059952b4d > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users