[fossil-users] Extra code in autosetup/local.tcl
Hi Joe, I was just looking at autosetup/local.tcl and I see back in 2014 you committed 3a5c9b34f39be09b contain a bunch of extra code. It looks like this is copied from jim local.tcl I suggest deleting everything from '# The complex extension checking is done here.' onwards to avoid confusion. Cheers, Steve -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
Hi all: In message <787dd2f8-edf8-4caf-5d8c-b63cac39a...@marples.name>, Roy Marples writes: >On 26/03/2017 22:19, Joerg Sonnenberger wrote: >> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote: >>> For someone with a different background, there is *nothing* nice about >>> fossil dumping thousands of lines to the terminal. In fact, I think it >>> scares off newbies who only used git before. >> >> I quite disagree. Terminal output is C&P friendly. Pager output tends to >> disappear with the pager. That's a real world UX issue I have with the >> git default settings. > >Pager output disappearing with the pager (I assume when asking the pager >to exit) is an issue with the pager. > >As Fossil is a single binary to do everything approach, I'm sure that a >Fossil pager would not suffer this defect. IIRC the patch is using an external pager right? There is not a pager being build into fossil. >Yes, terminals have scroll bars and can page up, but that's the wrong >approach as well. > >When viewing a diff I want to start at the top and scroll down, not >start at the bottom and scroll up, hence a pager makes perfect sense. As long as it can be turned off so wrappers around fossil (fsl, emacs vc mode, other programs using the cli as a fossil interface) are not broken if terminal detection fails, I'm meh about it. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. On 26/03/2017 22:19, Joerg Sonnenberger wrote: > On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote: >> For someone with a different background, there is *nothing* nice about >> fossil dumping thousands of lines to the terminal. In fact, I think it >> scares off newbies who only used git before. > > I quite disagree. Terminal output is C&P friendly. Pager output tends to > disappear with the pager. That's a real world UX issue I have with the > git default settings. Pager output disappearing with the pager (I assume when asking the pager to exit) is an issue with the pager. As Fossil is a single binary to do everything approach, I'm sure that a Fossil pager would not suffer this defect. Yes, terminals have scroll bars and can page up, but that's the wrong approach as well. When viewing a diff I want to start at the top and scroll down, not start at the bottom and scroll up, hence a pager makes perfect sense. Roy ___ 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
On 26/03/2017 22:19, Joerg Sonnenberger wrote: On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote: For someone with a different background, there is *nothing* nice about fossil dumping thousands of lines to the terminal. In fact, I think it scares off newbies who only used git before. I quite disagree. Terminal output is C&P friendly. Pager output tends to disappear with the pager. That's a real world UX issue I have with the git default settings. Pager output disappearing with the pager (I assume when asking the pager to exit) is an issue with the pager. As Fossil is a single binary to do everything approach, I'm sure that a Fossil pager would not suffer this defect. Yes, terminals have scroll bars and can page up, but that's the wrong approach as well. When viewing a diff I want to start at the top and scroll down, not start at the bottom and scroll up, hence a pager makes perfect sense. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Endless loop in fossil merge (legacy version)
2017-03-26 20:02 GMT+02:00 Francois Vogel: > So it works with fossil-1.33 but not with 1.35. > > Is this problem known? It looks fixed with 2.1 (but it's much slower than > with 1.33): Yes, this was a known bug fixed here:
[fossil-users] Newbie Fossil Hosting and Culture
>...
> Date: Sun, 26 Mar 2017 13:18:08 -0400
> From: Richard Hipp
>...
> Subject: [fossil-users] GitLab v. Fossil. Was: Eric Raymond (a.k.a.
> ESR) haspublished an SCM
> Message-ID:
>
>...
> What can Fossil and/or GitLab do to make it easier for newbies to set
> up new project instances on their own private servers? (See
> https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki for the
> documentation on how to create a server instance for Fossil.)
>...
I can't speak for others, but as a person/freelancer, who
has created my own PHP-webapp for hosting/semi-hiding
client project specific Fossil repositories, along my
open source project repositories,
some pre-made wrapper that allows the Fossil
to be used at cheap PHP-hosting sites might be very practical.
Link to my webapp that I wrote only for
my personal use (me + my clients)
and which is currently too big of a mess to be shared:
http://business.softf1.com/flaws/en/
(The semi-hiding part is based on hard-to-guess, long, URLs.
For demo, please compare redirection URLs
of projects with the project IDs:
silktorrent{my open, non-hidden, repo}
testrepo_1 {tests the semi-hiding feature}
The few-second-delay is a security related,
intentional, sleep call at my PHP code.
)
My current version, at my site, which I have been using for years,
uses some hack that uses some mixture of PHP, CGI, but
I remember that once upon a time I made some experiment, where
a plain PHP-program executed "a console program"(fossil binary)
and then dumped the output of that "console program"
as the reply to the query that the PHP program received.
However, I haven't tested that PHP-wrapper extensively
and as nobody really asked for it, I postponed that task, because it
takes some effort to document it and package it all properly.
I remember that a thing that I needed to test and that
I left untested was that the PHP interpreter has a parameter
which determines the maximum upload size of a file and
I wanted to find out, whether the chunks that the Fossil
uses for uploading files greater than the PHP upload limit
are kept, or at least can be configured to be kept,
"small enough" to be below the upload limits of the PHP interpreter.
I offer my clients, without any extra charge,
an opportunity to download their project's repository.
The idea behind the wrapper is that the PHP-wrapper
was supposed to simplify A CHEAP re-hosting of that repository.
For example, in Estonia there's even a web hosting service
that offers a PHP based hosting service for a price
that is literally about 1EUR/month:
https://www.planet.ee/
(It targets only Estonian market, so their web page
does not even have English texts, but in practice
literally all of the younger generation of Estonians
speaks/reads/writes English, so anybody can send
an e-mail in English to any Estonian company,
even, when the use of English is not advertised.)
As a matter of fact, the main reason, why I ended
up using Fossil at all, is that I wished to host/create
private repositories CHEAPLY for every client,
without being dependent on any American or
Western-European hosting providers.
The possibility to give to a client everything,
the wiki, the bug-reports, all of the project history,
in one easily re-hostable file PERFECTLY matches my use case.
I also love the idea that the Fossil is created CAREFULLY,
WITH CARE, not slammed together sloppily and forgotten to bitrot.
(Read: I like the development/work discipline of the Fossil developers,
specially that of the Richard Hipp)
The background story, why I want to host the repositories myself,
instead of using a paid private repository hosting service like GitHub,
consists of mainly 2 points:
x) 5$/month for every GitHub-or-alike private repository
for years for a micro-project that
only has a whole stage-1 budget of 300$ is absurdly expensive.
x) I want my client repositories to be outside of the
grasp of American style censorship.
(Privacy is currently missing, because I'm buying the hosting
service and the hosting service provider has access to the
repository files and internet traffic.)
A few words about the American/Wester-European style censorship:
Hosting service quality, at least according to my
very subjective view, includes
the upload/download speeds, HDD-speeds and UPTIME.
The UPTIME literally APPROACHES ZERO,
if the hosting service provider
TAKES THE HOSTED MATERIAL/PROCESSES/VirtualAppliances OFFLINE.
All those fancy redundant power supplies and
redundant internet connections that the hosting provider
has at its data center become TOTALLY USELESS,
if the hosting provider takes its clients' material offline,
including the cases, where the hosting provider does it
due to Censorship. For example, one
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote: > For someone with a different background, there is *nothing* nice about > fossil dumping thousands of lines to the terminal. In fact, I think it > scares off newbies who only used git before. I quite disagree. Terminal output is C&P friendly. Pager output tends to disappear with the pager. That's a real world UX issue I have with the git default settings. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Push transfer script
I’m working on setting up my Fossil server so that certain tasks are kicked off
after someone pushes changes to it. Push transfer scripts seem like the right
tool for this. Because of the nature of the work that needs to happen after a
push, I have my TH1 script ‘tclInvoke exec’ an external script that takes the
hash of a checkin contained in the push. Something like:
tclInvoke exec /bin/sh -c “foo.sh $hash" >> /tmp/commit_hook.log
Where $uuid is a TH1 variable containing the hash of a checkin.
My script needs to collect some information about the checkin so it does the
following to get the manifest:
echo "select content(‘${hash}');" | fossil sql -R foo.fossil
When testing the script in isolation, this works great. However, when run from
a push transfer script, the artifact identified by the hash isn’t found.
Looking through the source to Fossil it looks like the push transfer script
gets executed before the database transaction for the push has been committed.
So, it makes sense that my script wouldn’t find the artifact in question.
The Fossil UI describes the Push transfer script as: 'Specific TH1 code to run
after "push" transfer requests.’ I was reading the “after” to mean after the
push had been committed to the Fossil database, but this isn’t how it is
implemented.
This leaves me with the following questions:
- Is it intentional that the push transfer script is executed before the push
has been committed or is this a bug? (I can see the utility of a script
executes before a push is committed in order to give it the chance to reject
the push, but I’m not sure if this is the intent here).
- If it is intentional, would a patch implementing a “post-push” transfer
script that only gets executed after the push has been committed be acceptable?
- Are there other suggestions that I haven’t though of?
Thanks,
--
Ryan
___
fossil-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 Captchas
On Sun, Mar 26, 2017 at 9:06 PM, Richard Hipp wrote: > I am also now reminded that there is an option on the Setup/Access > page that adds a button to the CAPTCHA that completes the captcha > automatically. That would nicely facility access via screen readers. > i was about to say the same thing (Admin ==> Setup ==> auto-captcha), but it appears to have been broken. On my recently-update site it's not working, anyway (the button doesn't appear). i haven't looked into why (i'm still limited to how much i can operate a keyboard), but speculate that it "might" have been purposely removed, as bots can mostly understand JavaScript nowadays. -- - 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 Captchas
On 3/26/17, Damien Sykes-Lindley wrote: > Hi Richard, > Forgive me if I'm mistaken, but I think the anonymous password shows itself > as a captcha. The following quote from the antibot article would seem to > confirm this: > > "The "anonymous" user is also available for humans who do not wish to > identify themselves. The difference is that "anonymous" requires a login > (using a password supplied via a CAPTCHA)" Hmm... I suppose you do have to enter the CAPTCHA if you want to log in as anonymous. My point is, though, that sites like Fossil and SQLite are configured such that anonymous log-in is not required. I am also now reminded that there is an option on the Setup/Access page that adds a button to the CAPTCHA that completes the captcha automatically. That would nicely facility access via screen readers. > > Below that there are several lines of underscores and bars, I'm assuming > this is an ascii-based captcha or some other method of obscurity, since I > can't find any clear 8-digit hexadecimal sequence. Correct. The CAPTCHA is an ascii-art rendering of the 8-digit hex key. -- 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
Re: [fossil-users] Fossil Captchas
Hi Richard, Forgive me if I'm mistaken, but I think the anonymous password shows itself as a captcha. The following quote from the antibot article would seem to confirm this: "The "anonymous" user is also available for humans who do not wish to identify themselves. The difference is that "anonymous" requires a login (using a password supplied via a CAPTCHA)" The login page states: "Visitors may enter anonymous as the user-ID with the 8-character hexadecimal password shown below:" Below that there are several lines of underscores and bars, I'm assuming this is an ascii-based captcha or some other method of obscurity, since I can't find any clear 8-digit hexadecimal sequence. Cheers. Damien. -Original Message- From: Richard Hipp Sent: Sunday, March 26, 2017 7:38 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Fossil Captchas On 3/26/17, Damien Sykes-Lindley wrote: Hi there, Is there any chance an option can be added in Fossil whereby, when/where a captcha is required, the task is to answer a question instead? That could be done, in theory, but augmenting a few routines in the captcha.c source file. Consider sending in patches. But, I thought the design of Fossil had moved past the need for captchas for robot control. See http://localhost:591/fossil/doc/trunk/www/antibot.wiki for details. I just now logged off and went surfing about on the canonical Fossil repo and did not find any pages requesting a captcha. Do you have an example that I have overlooked? -- 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 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.
On 3/26/17, arnoldemu wrote: >>fossil update > Autosync: http:///arnold > Autosync failed. > This fossil repository is not compatible with the version of your client. > You need version 2.1 or later. Please visit http://www.fossil-scm.org and > download a new client. The difficulty there is that when the older version of Fossil that is running the "update" was written, we didn't know about version 2.1 and so there wasn't any way for us to add an error message about needing 2.1. :-) -- 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
Re: [fossil-users] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM
On 03/26/17 19:18, Richard Hipp wrote: [---] > (i) With Fossil, one can click on two nodes of the graph to see a > diff between those two nodes. With GitLab, you apparently have to go > to the separate "Compare" screen, then many type in (or paste in) hash > name prefixes of the two check-ins you want to compare. This seems > rather clumsy. But maybe I'm missing something. This is the same in Bitbucket. I use the version compare feature in the timeline in Fossil *a lot*; I'd almost be willing to stretch to say "literally daily", but I'm sure there's been a day when I haven't used it -- but you get the point. When I helped install a development environment based on the Atlassian products a while ago I was quite shocked that Bitbucket didn't support the feature. Considering how useful it is, I had never occurred to me that a modern UI _wouldn't_ have it. Anyway, I searched around to see if it was available in an alpha version or something somewhere, and quickly realized others wanted the feature as well. However, no good news on that front: The idea was apparently "No, you use tool X for that.". (As it happens, this tool X was a desktop application for the local checkout, which - in my mind - kind of defeated the purpose). Maybe this is tangentially related to the cathedral vs bazaar discussion; with Fossil, you typically have a central point where "all" the useful checkins end up. -- 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
Re: [fossil-users] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.
Hi Richard, >The "auto" hash-policy automatically flips to "sha3" as soon as Fossil >sees one or more SHA3 artifacts in the repo. Since your repo contains >SHA3 artifacts, you won't be able to set the policy to "auto" because >it will immediately and automatically flip to "sha3". > >That is the way "auto" is designed to work. I expected it to automatically do that when I did a "fossil update" and get the files provided I had fossil 2.1 installed. I have autosync set and I thought that would then sync from the server and automatically switch to sha3 and get the new files. >How were you expecting it to work? How can the documentation be improved? Setting the hash policy was fine that worked without confusion. When I then accessed the remote repository from another machine I expected it to automatically see the change and automatically switch the client to the new policy. If the client needed to be updated then ideally fossil client should tell me. It would have been great if this is what had happened: >fossil update Autosync: http:///arnold Autosync failed. This fossil repository is not compatible with the version of your client. You need version 2.1 or later. Please visit http://www.fossil-scm.org and download a new client. Then after installing the new client and with the hash-policy set to auto: >fossil update Autosync: http:///arnold Hash-policy on server has been updated to sha3. Switching to sha3 for client. ... <- normal sync here with cards and files listed. If I had set the policy to sha1 or other: >fossil update Autosync: http:///arnold Autosync failed. The fossil repository is using sha3 hash policy. Please set hash-policy to sha3 or use auto. Maybe for now, instead of (or in addition) to the errors I saw it could give a command to try to resolve the issue such as one that causes the database to update. Thank you Kevin ___ fossil-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 Captchas
On 3/26/17, Damien Sykes-Lindley wrote: > Hi there, > Is there any chance an option can be added in Fossil whereby, when/where a > captcha is required, the task is to answer a question instead? That could be done, in theory, but augmenting a few routines in the captcha.c source file. Consider sending in patches. But, I thought the design of Fossil had moved past the need for captchas for robot control. See http://localhost:591/fossil/doc/trunk/www/antibot.wiki for details. I just now logged off and went surfing about on the canonical Fossil repo and did not find any pages requesting a captcha. Do you have an example that I have overlooked? -- 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] Endless loop in fossil merge (legacy version)
Hi, FYI, this is on Windows in the Tk repository: http://core.tcl.tk/tk/ I get an endless loop in fossil as follows: C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil version This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil status repository: C:/Users/francois/Documents/Development/tcltk-fossil/tk/../tk.fossil local-root: C:/Users/francois/Documents/Development/tcltk-fossil/tk/ config-db:C:/Users/francois/AppData/Local/_fossil checkout: 44e27f3e7b8f6b7e2916193fa35edb5c6d34dab3 2017-01-25 22:05:51 UTC parent: bfb8e49e36e348536b46afb72fa0029645dc921d 2017-01-23 09:45:18 UTC child:b20b6d95b46553a7eb856529faf5d3d440fcde0b 2017-03-26 15:14:51 UTC merged-into: 8912c3c5a73ccd7b684e52403094e5c8d0903cb0 2017-01-25 22:08:59 UTC tags: core-8-5-branch comment: Fix [140ea8ab38]: Long text lines are not drawn on Windows. (user: pspjuth) C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil merge --dry-run --baseline 1896a918 tip-464 ^C (I had to cancel it manually: 100% CPU for many many minutes) C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil-1.33.exe merge --dry-run --baseline 1896a918 tip-464 UPDATE generic/ks_names.h UPDATE xlib/X11/keysymdef.h MERGE doc/keysyms.n MERGE win/tkWinKey.c REMINDER: this was a dry run - no files were actually changed. (processed the command lickity split, with correct output) So it works with fossil-1.33 but not with 1.35. Is this problem known? It looks fixed with 2.1 (but it's much slower than with 1.33): C:\Users\francois\Documents\Development\tcltk-fossil\tk>fossil-2.1.exe merge --dry-run --baseline 1896a918 tip-464 UPDATE generic/ks_names.h UPDATE xlib/X11/keysymdef.h MERGE doc/keysyms.n MERGE win/tkWinKey.c REMINDER: this was a dry run - no files were actually changed. You can try it on the above given repo. Thanks, Francois ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Sun, 26 Mar 2017 19:25:25 +0200 Christophe Gouiran wrote: > I see that most of you complain about this proposed feature. TBH, many members of this list live in the UNIX greybeard bubble, and that's why there is so much opposition to this feature. They're used to the original UNIX way and they have different expectations than most of users. For someone with a different background, there is *nothing* nice about fossil dumping thousands of lines to the terminal. In fact, I think it scares off newbies who only used git before. Anyway, there's no point in arguing about it. This feature will be optional, no one is forcing anyone to change their habits. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Mar 26, 2017 11:25 AM, "Christophe Gouiran" wrote: Please find as attached file another patch which: 1. First test for a real terminal before spawning the pager command. 2. No more paginate json command. I see that most of you complain about this proposed feature. It was only a proposition, if it is not accepted I won't care. However, it would be possible to make both world happy: 1. Those who don't like this feature simply don't set a pager-command setting. 2. Those who want to use it set a pager-command setting. And, IMHO adding or removing a '|' at the end of command names is not a maintenance nightmare. I'm sorry if I've offended. My point was that one code path that works with all future commands or changes to commands is not bad, even if it is not something I will personally use. Needing to tweak code paths unrelated to DVCS functionality to maintain this feature going forward seems less than ideal. I do commend you for stepping forward to implement it. I just disagree with the idea of making it command specific. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
Please find as attached file another patch which:
1. First test for a real terminal before spawning the pager command.
2. No more paginate json command.
I see that most of you complain about this proposed feature.
It was only a proposition, if it is not accepted I won't care.
However, it would be possible to make both world happy:
1. Those who don't like this feature simply don't set a pager-command
setting.
2. Those who want to use it set a pager-command setting.
And, IMHO adding or removing a '|' at the end of command names is not a
maintenance nightmare.
Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
if( showLabel ){
int len = (int)strlen(zFilename);
int nStar = 80 - (len + 15);
if( nStar<2 ) nStar = 1;
fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
- fflush(stdout);
+ fflush(our_stdout);
}
if( !quiet || dryRunFlag ){
fossil_print("%s\n", zSyscmd);
- fflush(stdout);
+ fflush(our_stdout);
}
rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
free(zSyscmd);
free(zQFilename);
if( stopOnError && rc ){
Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
blob_is_init(pBlob);
#if defined(_WIN32)
nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
#endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
#if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
#endif
}else{
file_mkfolder(zFilename, 1, 0);
out = fossil_fopen(zFilename, "wb");
if( out==0 ){
Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
);
}
/*
-** COMMAND: branch
+** COMMAND: branch|
**
** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
**
** Run various subcommands to manage branches of the open repository or
** of the repository identified by the -R or --repository option.
Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
}
db_end_transaction(0);
}
/*
-** COMMAND: bundle
+** COMMAND: bundle|
**
** Usage: %fossil bundle SUBCOMMAND ARGS...
**
** fossil bundle append BUNDLE FILE...
**
Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
if( relPathOption ){ relativePaths = 1; }
return relativePaths;
}
/*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
**
** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
**
** Report the change status of files in the current checkout. If one or
** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
}
db_finalize(&q);
}
/*
-** COMMAND: ls
+** COMMAND: ls|
**
** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
**
** List all files in the current checkout. If PATHS is included, only the
** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
}
db_finalize(&q);
}
/*
-** COMMAND: extras
+** COMMAND: extras|
**
** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
**
** Print a list of all files in the source tree that are not part of the
** current checkout. See also the "clean" command. If paths are specified,
@@ -872,11 +872,11 @@
}
blob_reset(&report);
}
/*
-** COMMAND: clean
+** COMMAND: clean|
**
** Usage: %fossil clean ?OPTIONS? ?PATH ...?
**
** Delete all "extra" files in the source tree. "Extra" files are files
** that are not officially part of the checkout. If one or more PATH
Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -209,14 +209,14 @@
db_open_repository(g.argv[3]);
}
db_begin_transaction();
fossil_print("Rebuilding repository meta-data...\n");
rebuild_db(0, 1, 0);
- fossil_print("Extra delta compression... "); fflush(stdout);
+ fossil_print("Extra delta compression... "); fflush(our_stdout);
extra_deltification();
db_end_transaction(0);
- fossil_print("\nVacuuming the database... "); fflush(stdout);
+ fossil_print("\nVacuuming the database... "); fflu
Re: [fossil-users] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.
On 3/26/17, arnoldemu wrote: > > So it seems that hash-policy of auto is not working? > The "auto" hash-policy automatically flips to "sha3" as soon as Fossil sees one or more SHA3 artifacts in the repo. Since your repo contains SHA3 artifacts, you won't be able to set the policy to "auto" because it will immediately and automatically flip to "sha3". That is the way "auto" is designed to work. How were you expecting it to work? How can the documentation be improved? -- 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] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM
On 3/26/17, Stephan Beal wrote: > It seems that ESR has published his own SCM: > > http://esr.ibiblio.org/?p=7448 > http://www.catb.org/esr/src/ Thanks for pointing this out, Stephan. What intrigues me most here is not ESR's python-script wrapper around RCS/SCCS, but rather the GitLab interface. I had heard of GitLab, but had never before taken the time to look into it. My first impression is that it seems much nicer than GitHub. I mirrored a snapshot of ESR's GitLab repo using Fossil here: https://www.fossil-scm.org/tmp/esr-src (As you might infer from the "/tmp/" term in the URL, this is not a permanent link.) I think it is useful to compare the two interfaces, GitLab vs. Fossil. In particular, compare: https://www.fossil-scm.org/tmp/esr-src https://gitlab.com/esr/src/tree/master Two big questions: (1) What can Fossil learn from GitLab's interface? What ideas are there that can be copied from GitLab in order to improve Fossil? (2) What can GitLab learn from Fossil's interface? What ideas are there in Fossil that GitLab might copy for its benefit. I CC'ed "commun...@gitlab.com" on this reply with the hopes that they might join in the discussion. Under question (2) I'd like to make the following suggestions, in case somebody from gitlab actually reads this: (i) With Fossil, one can click on two nodes of the graph to see a diff between those two nodes. With GitLab, you apparently have to go to the separate "Compare" screen, then many type in (or paste in) hash name prefixes of the two check-ins you want to compare. This seems rather clumsy. But maybe I'm missing something. (ii) The timeline in Fossil is a lot faster than the graph of GitLab. (iii) I could not find any way to download tarballs of specific check-ins. Maybe I'm just not seeing it, but I could not find a way to get at the source code without cloning the repository. Under question (1) I offer the following: (iv) The "Branches" page seems to be busted. I think this is probably due to some kind of problem with the "fossil import" command that was used to convert the original Git repo. A general question to which I do not know the answer: How difficult would it be to stand up a GitLab community-edition instance for ESR's project? How does this compare with standing up a Fossil instance. I, of course, find Fossil a lot easier since I am familiar with it. But what do people say who do not have a bias one way or the other. What can Fossil and/or GitLab do to make it easier for newbies to set up new project instances on their own private servers? (See https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki for the documentation on how to create a server instance for Fossil.) -- 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
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
Sergei Gavrikov decía, en el mensaje "Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager" del 25/3/2017 14:09:57: > My 2 cents. Many of us use f-alias to deal with fossil in a terminal, > right? Then why not f-function? Maybe because not everybody uses Unix-like operating systems? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil 1.2->2.1 - hash policy "auto" doesn't seem to work and gives SQL error.
Hi All, i downloaded windows version of fossil 2.1 - after initial problems crashing when I ran it (see other thread) and rebuilding it was fine. I used fossil hash-policy to set it to sha3 and forced a commit to the server because I didn't have files in my changes at that time. From then on commits were using sha3 fine on windows. So I went to my linux machine. It was using fossil 1.2. I got this: kevin@kevin:~/arnold$ fossil update Autosync: http://kev@xxx/arnold Round-trips: 1 Artifacts sent: 0 received: 0 unknown command: [igot] Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 353 received: 2161 ip: x Autosync failed. continue in spite of sync failure (y/N)? n update abandoned due to sync failure I then downloaded linux x64 pre-compiled 2.1 kevin@kevin:~/arnold$ fossil version This is fossil version 2.1 [83e3445f67] 2017-03-10 17:07:08 UTC kevin@kevin:~/arnold$ fossil hash-policy auto kevin@kevin:~/arnold$ fossil update Autosync: http://kev@xxx/arnold Round-trips: 1 Artifacts sent: 0 received: 0 SQLITE_CONSTRAINT: abort at 14 in [INSERT INTO blob(rcvid,size,uuid,content)VALUES(0,-1,:uuid,NULL)]: CHECK constraint failed: blob fossil: SQL error: CHECK constraint failed: blob kevin@kevin:~/arnold$ fossil hash-policy sha3 sha3 kevin@kevin:~/arnold$ fossil update Autosync: http://kev@xx/arnold Round-trips: 3 Artifacts sent: 0 received: 202 Pull done, sent: 8806 received: 157107 ip: xxx UPDATE changes.txt ... So it seems that hash-policy of auto is not working? This is a rough sequence of events: * fossil 1.2 exe on windows and on linux * fossil server updated to 2.1 * I updated windows binary to 2.1 * on windows I used hash-policy to set sha3 and used force because there were no more changes * committed some files on windows * I tried to update with linux 1.2 binary * I then updated to linux 2.1 binary * I then had to set sha3 policy (auto didn't work - see error) * update succeeded. Thanks Kevin ___ 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 Captchas
Hi there, Is there any chance an option can be added in Fossil whereby, when/where a captcha is required, the task is to answer a question instead? I say this because, as a totally blind screen reader user, captchas are generally inaccessible to us. Ordinarily, most sites have an audio captcha feature (I fully appreciate that would possibly be difficult to add). Where this isn’t an option, there are helpers out there that OCR and clear the image to give us the answer (Again, I appreciate that helps us but totally undermines the reason for the existence of the captcha in the first place). Fossil seems not to employ either of these methods but instead represents it with bars and underscores (I actually thought it was some sort of bug when I found it, until I read that it used a captcha-style password representation). This is why I thought of the idea of a question (such as a calculation, or even a user supplied one), as an alternative option. Just my thoughts. Cheers. Damien. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Sun, 26 Mar 2017 16:00:11 +0200, Scott Robison
wrote:
On Mar 26, 2017 7:13 AM, "Christophe Gouiran"
wrote:
Hi all,
First of all many thanks for all your feedback.
I come back to you with an implemented solution.
After many thinking, for me not all commands need to send their outputs
to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:
{snipped list of commands}
I appreciate what you're trying to do here, but what you've done (based
on
your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.
I'm coming around to the position that, given the ease of typing "|
pager"
when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done
this
for me, though I could be in the minority.
+1
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Sun, Mar 26, 2017 at 4:00 PM, Scott Robison wrote: > their amount of output, perhaps based on some extra parameter. DRH > suggested that it should be based on any output, which would avoid the > worry about how fossil changes over time. > corner case: json output should arguably never be paged. FWIW, i consider built-in paging (and symlinks support and fossil-side terminal line-wrapping, for that matter) to be a bad idea (read as: "can of worms"). i can count on one hand the number of times i've pager'd fossil output since 2007. -- - 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Mar 26, 2017 7:13 AM, "Christophe Gouiran"
wrote:
Hi all,
First of all many thanks for all your feedback.
I come back to you with an implemented solution.
After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:
{snipped list of commands}
I appreciate what you're trying to do here, but what you've done (based on
your description) is create a maintenance nightmare (or headache at
minimum). Your implementation will forever need to be tweaked when new
commands are added or existing commands changed in some way that changes
their amount of output, perhaps based on some extra parameter. DRH
suggested that it should be based on any output, which would avoid the
worry about how fossil changes over time.
I'm coming around to the position that, given the ease of typing "| pager"
when desired, or defining an alias or using a wrapper of sorts, this
feature may be a mistake. I've never once wished that fossil had done this
for me, though I could be in the minority.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On 2017-03-26 15:13:53, Christophe Gouiran wrote: > I come back to you with an implemented solution. > Your solution doesn't check whether stdout is actually pointing to a terminal. You should never invoke a pager if it's not. I also think this is a horrible idea in general. Regards, -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Eric Raymond (a.k.a. ESR) has published an SCM
It seems that ESR has published his own SCM: http://esr.ibiblio.org/?p=7448 http://www.catb.org/esr/src/ "Simple Revision Control is RCS/SCCS reloaded with a modern UI, designed to manage single-file solo projects kept more than one to a directory. Use it for FAQs, ~/bin directories, config files, and the like. Features integer sequential revision numbers, a command set that will seem familiar to Subversion/Git/hg users, and no binary blobs anywhere." -- - 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
Hi all,
First of all many thanks for all your feedback.
I come back to you with an implemented solution.
After many thinking, for me not all commands need to send their outputs to
a pager.
Only ones which may output a big amount of lines in a bunch.
Therefore, I selected only some of them to be candidate for a pager:
1. branch
2. bundle
3. changes
4. status
5. ls
6. extras
7. clean
8. artifact
9. descendants
10. leaves
11. annotate
12. blame
13. praise
14. diff
15. finfo
16. cat
17. json
18. search
19. tag
20. timeline
21. ticket
22. undo
23. redo
24. unversioned
25. wiki
To achieve that, I modified mkindex.c and, in all relevant source files, I
appended a pipe '|' to the commands which are candidates for a pager.
Now, when fossil is launched, it decides whether to use a pager according
to following conditions in this order of priority:
1. Fossil command is candidate for a pager.
2. PAGER environment variable is set to a non empty value.
3. pager-command setting is set to a non empty value.
Then, technically, when there is pager to use it is launched as a child
process and Fossil standard output stream is piped to pager standard input.
And Fossil waits for pager to quit before quitting itself.
Just give it a try : it works pretty well under Linux with pager-command
"less -FRX".
It does not work yet under Windows as I'm a complete newbie with its
programming API.
If someone wants to contribute for the Windows, it would be welcome.
As usual, waiting for your feedback ...
Note : provided patch can be applied against latest version of the trunk
([a0ce33c90b] at the time of this writing).
Index: src/allrepo.c
==
--- src/allrepo.c
+++ src/allrepo.c
@@ -418,15 +418,15 @@
if( showLabel ){
int len = (int)strlen(zFilename);
int nStar = 80 - (len + 15);
if( nStar<2 ) nStar = 1;
fossil_print("%.13c %s %.*c\n", '*', zFilename, nStar, '*');
- fflush(stdout);
+ fflush(our_stdout);
}
if( !quiet || dryRunFlag ){
fossil_print("%s\n", zSyscmd);
- fflush(stdout);
+ fflush(our_stdout);
}
rc = dryRunFlag ? 0 : fossil_system(zSyscmd);
free(zSyscmd);
free(zQFilename);
if( stopOnError && rc ){
Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -859,17 +859,17 @@
if( zFilename[0]==0 || (zFilename[0]=='-' && zFilename[1]==0) ){
blob_is_init(pBlob);
#if defined(_WIN32)
nWrote = fossil_utf8_to_console(blob_buffer(pBlob), blob_size(pBlob), 0);
if( nWrote>=0 ) return nWrote;
-fflush(stdout);
-_setmode(_fileno(stdout), _O_BINARY);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_BINARY);
#endif
-nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), stdout);
+nWrote = fwrite(blob_buffer(pBlob), 1, blob_size(pBlob), our_stdout);
#if defined(_WIN32)
-fflush(stdout);
-_setmode(_fileno(stdout), _O_TEXT);
+fflush(our_stdout);
+_setmode(_fileno(our_stdout), _O_TEXT);
#endif
}else{
file_mkfolder(zFilename, 1, 0);
out = fossil_fopen(zFilename, "wb");
if( out==0 ){
Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -261,11 +261,11 @@
);
}
/*
-** COMMAND: branch
+** COMMAND: branch|
**
** Usage: %fossil branch SUBCOMMAND ... ?OPTIONS?
**
** Run various subcommands to manage branches of the open repository or
** of the repository identified by the -R or --repository option.
Index: src/bundle.c
==
--- src/bundle.c
+++ src/bundle.c
@@ -716,11 +716,11 @@
}
db_end_transaction(0);
}
/*
-** COMMAND: bundle
+** COMMAND: bundle|
**
** Usage: %fossil bundle SUBCOMMAND ARGS...
**
** fossil bundle append BUNDLE FILE...
**
Index: src/checkin.c
==
--- src/checkin.c
+++ src/checkin.c
@@ -350,12 +350,12 @@
if( relPathOption ){ relativePaths = 1; }
return relativePaths;
}
/*
-** COMMAND: changes
-** COMMAND: status
+** COMMAND: changes|
+** COMMAND: status|
**
** Usage: %fossil changes|status ?OPTIONS? ?PATHS ...?
**
** Report the change status of files in the current checkout. If one or
** more PATHS are specified, only changes among the named files and
@@ -644,11 +644,11 @@
}
db_finalize(&q);
}
/*
-** COMMAND: ls
+** COMMAND: ls|
**
** Usage: %fossil ls ?OPTIONS? ?PATHS ...?
**
** List all files in the current checkout. If PATHS is included, only the
** named files (or their children if directories) are shown.
@@ -802,11 +802,11 @@
}
db_finalize(&q);
}
/*
-** COMMAND: extras
+** COMMAND: extras|
**
** Usage: %fossil extras ?OPTIONS? ?PATH1 ...?
**
** Print a list of all files i
Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager
On Sat, 25 Mar, Andy Bradford wrote: > Thus said Roy Keene on Thu, 23 Mar 2017 17:36:37 -0500: > > > I vote that the pagination be off by default to preserve the > > existing behaviour -- terminals have been able to scroll for > > decades now so I don't know why systemd/git like to do this by > > default but it is REALLY annoying having to pipe EVERYTHING through > > "cat" to defeat it. > > I'll add my voice to this as well and it's not just to preserve > existing behavior. I think git's default (is it even configurable > with git?) to automatically page everything is one of its most > annoying features. If I want a pager, I'll pipe it to a pager. > Otherwise, just dump it to my terminal, thank you. +1 for everything said by Roy and Andy. -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
