Re: [fossil-users] How to Embed WebM Videos to Fossil Wiki Pages?
On Wed, Jan 03, 2018 at 07:04:20PM +0200, Martin Vahi wrote: Hi there, I am not related to the fossil project, so don't take this as any way official. > I know that the way to embed an image is by > > ![name of the link]() > > but it does not seem to work with the WebM videos. It is probably worth being very clear about what you are seeing and wanting. The above syntax is (according to https://www.fossil-scm.org/xfer/md_rules) a way of including in-line images within markdown-formatted pages. When you say "it does not seem to work", do you mean "it does not become "img src=" in the output html"; or "it does become "img src=" in the output html, but I want it to become something else instead"? I suspect that the answer is the latter, which means that it *does* work as it is designed to. What you (presumably) want is for some markdown syntax that will become "video src=" in the output html, possibly with some extra words included. It would probably be good if you can specific exactly what output-html you want, in order to avoid any unnecessary guessing. Rather than the fossil-project making up its own markdown syntax for embedded videos, can you point to a description of the markdown syntax that is already well-known for embedding videos? That might inspire someone who is interested to write the code to implement things. Note that I can see, for example, https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#videos which says """ Image tags with a video extension are automatically converted to a video player. The valid video extensions are .mp4, .m4v, .mov, .webm, and .ogv. """ (personally, I think that "match the extension" is the wrong thing to do; but I'm neither designing the spec nor intending to write the implementation, so my opinion is less important) and which converts the markdown-input """  """ into the html-output """ Sample Video """ when I look at it. Is that "the" authoritative source for markdown-for-video? Is "exactly that list of five extensions" the thing that fossil should deal with? Note that currently (I think) the fossil markdown-parser does not try to interpret what you write inside the () -- it is a string which is html-escaped before being written. Perhaps it would be better to have different markdown syntax for video, so that the markdown-parser could continue not to care about the content of the (); and could also allow any future video format to be handled seamlessly. Is there another markdown-family that has addressed video before now? What syntax did they use? As I understand it, if the browser sees " The lack > of WebM video support seems to be something that > I seem to stumble upon repeatedly. I suggest that the best "next step" is for you to define your desired input-to-output mappings, ideally with reference to places that have considered doing the same thing before now. If there were syntaxes that were rejected, it would be good to know why. If there were syntaxes that were accepted, it would be good to see how well they work in practice. Without thinking much about it, perhaps !![]() would be suitable for a video element -- it resembles the current image element of ![](), but is different enough that one will not be confused for the other. (But perhaps that breaks something else in the markdown-syntax-rules. Who knows?) Good luck with it. If no-one cares to write the code, then it cannot be integrated. If no-one cares to write the spec, then it is unlikely that someone will be convinced to write the code. f -- Francis Dalyfran...@daoine.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] bug(?) in glob handling on exact match?
On Thu, Nov 02, 2017 at 04:12:59PM +0100, Stephan Beal wrote: Hi there, > i'm not sure if this is a bug or not, but it looks like one... I don't think so. https://www.fossil-scm.org/xfer/doc/trunk/www/globs.md It's acting how it's documented to act. > # 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. 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. > i rather expected 'makefile' to work just like a normal glob and match any > matching filename. It works like a normal fossil glob; not like a Unix file glob. Cheers, f -- Francis Dalyfran...@daoine.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] Double forward slash when using --baseurl
On Sat, Sep 10, 2016 at 10:44:34AM +0100, Zombies wrote: > On 10 September 2016 at 01:52, Francis Daly wrote: > On Fri, Sep 09, 2016 at 08:27:53AM +0100, Zombies wrote: Hi there, Good that you got it working. > > > ./fossil server --baseurl "https://fossil.mydomain.com:443/"; > > repos/myRepo > > > > "baseurl" must start with "http://"; or "https://"; (enforced in code), > > and must not end in "/" (not enforced directly). It is good when you > > It seems to enforce an ending '"/", > If I try and use it without the ending '/' - it doesnt seem to like it at > all:- > > ./fossil server --baseurl "https://fossil.mydomain.com:443"; repos/myRepo > argument to --baseurl should be 'http://host/path' or 'https://host/path' Yes - it's a bit of a terminology confusion, but: the "/path" part is required (or the option is not accepted) *and* the "/path" must not end in "/" (or the double-slashes produced cause the output to break). So if you want your "repos/myRepo" as served by fossil, to appear to be at "/base/myrepos/myRepo" when served by the public-facing web server that hides fossil, then you would use "--baseurl http://whatever/base";. The one (common?) case where --baseurl does not work, is exactly your case: the public-facing web server just handles https but otherwise does not change the url. If you were using something like stunnel for https and spawning a new "fossil" for each incoming request, you could use "fossil http --https" But that is not available for "fossil server". As it happens, it does not matter that "--https" and "--baseurl" do not work in this case, because just setting the env-var does work. Cheers, f -- Francis Dalyfran...@daoine.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] Double forward slash when using --baseurl
On Fri, Sep 09, 2016 at 08:27:53AM +0100, Zombies wrote: > On 8 September 2016 at 20:23, Joe Mistachkin wrote: > > Zombies wrote: Hi there, > > > For the main web page links it is working fine, however on some of the > > pages, > > > I am getting links to pages with an extra '/' being inserted. It happens > > with > > > all of the links from the 'Admin' tab, e.g- > > > > > > > What is the full command line being used? > > > > > ./fossil server --baseurl "https://fossil.mydomain.com:443/"; repos/myRepo "baseurl" must start with "http://"; or "https://"; (enforced in code), and must not end in "/" (not enforced directly). It is good when you are "reverse-proxying" the connection to a different part of the url hierarchy. It is not good if you are just hiding behind https. If the front-end is just a load balancer (with ssl termination), and includes the "fossil.mydomain.com" Host: header in the requests that get to fossil, then possibly HTTPS=on ./fossil server repos/myRepo will cause it to Just Work for you. That is -- ensure that then environment variable HTTPS has the value "on" in the fossil process. Cheers, f -- Francis Dalyfran...@daoine.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] Justification for two-step mv and rm
On Fri, Mar 06, 2015 at 03:46:08PM +0100, j. van den hoff wrote: > On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna wrote: Hi there, > >I'd prefer that default `rm`/`mv` without options leave my file > >system alone. A `--forcefilesytem` flag would be a convenient > >enhancement. > > personally, I would _not_ like to see a mandatory > `--forcefilesystem' "option" in order to get the usually desired > behaviour. This discussion does seem to be taking more-or-less the same shape as the last time around. The end result then was: no change; whatever code was written was not accepted into stock fossil. This time, there is some code visible in the recent timeline, so maybe it will progress. I think there were three main "issues" brought up, with some opinions for and against each. I'll (try to) summarise them here; but do feel free to check and correct me if I've mischaracterised anything. * the current fossil commands "mv" and "rm" make changes to the repository, but not to the local filesystem. Issue 1 - there should be a way, in fossil, to make "the corresponding" changes to the filesystem. Issue 2 - that way should be the default for a command, not requiring a --option argument. Issue 3 - that command should be exactly "mv" or "rm". Issue 1 seemed to be generally positive, with a few questions about when exactly the filesystem changes should happen -- at command time or at commit time -- and with a question about what "revert" or other "undo" features should be available. Issue 2 seemed to be generally positive (once issue 1 is considered accepted); I don't think I saw any objections to the theory of it. Issue 3 seemed to be mixed. Those in favour were greatly in favour; those against were greatly against. The arguments were broadly what was seen in this thread, which is roughly: consistency with non-fossil things vs consistency with previous-fossil things. I don't think I've anything new to bring to the discussion. Hopefully the above notes are useful to clarify thoughts or recollections. Or possibly they are wrong or unsubtle enough to induce someone to expand on them. When the code is ready, it'll be time for the One Person to use the One Vote, and we'll see what's in the next version of fossil ;-) f -- Francis Dalyfran...@daoine.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] Justification for two-step mv and rm
On Wed, Mar 04, 2015 at 05:52:36PM -0700, Warren Young wrote: > On Mar 4, 2015, at 5:28 PM, Francis Daly wrote: > > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: > > I think that the principle of least surprise for non-users of fossil is > > (much) less important. > > I think there are many times more future users of Fossil than present users > of Fossil. Potential future users, yes. But (selfishly) they are not my concern. Other opinions exist, of course. > It will be easier to woo them if we’re not throwing pointless differences in > their way. Wooing them is not my ambition. Disturbing current actual users, few though they may be, is a definite negative. Possibly the positive for current actual users who want the behaviour change, plus whatever positive is associated with future users who will benefit from the behaviour change, outweighs the negative. That's a balance for the project to decide. > > For what it's worth, I do think that it would be useful to have a command > > to affect both the repository and the filesystem in similar ways. But I > > also think that historical baggage suggests that "rm" (or "mv") is not > > that command. > > There really isn’t any historical baggage with mv. Fossil’s the weird one > here. Some historical baggage is that right now, one (reasonable?) way to commit a file rename is fossil mv a b && mv a b && fossil commit -m mv If you're going to break that, do it deliberately and loudly. > > (I confess that I'm not clear on exactly how (or > > whether) "undo" or "revert" will become involved in the new > > remove-from-repository-and-filesystem command/argument. > > fossil mv is easy. It’s inherently undoable. I'm sure it can be, for all combinations of files and directories which do and do not exist before the "fossil repo+fs-mv", and which are created after that and before any "undo". But there's a whole new (I think) set of error cases in there. (I may be wrong; they may already be covered by "checkout", which would ease the documentation burden.) > The Mercurial approach to rm addresses this concern, too. It won’t allow rm > without -f if you have uncommitted local modifications. If you force it, > you’ve already given up on undo, IMHO. The tool tried to protect you from a > potential data loss, and you made it proceed anyway. Once the error indication and the "recovery advice" are clear, it'll be fine for interactive use or new scripting use. f -- Francis Dalyfran...@daoine.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] Justification for two-step mv and rm
On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: > On Mar 4, 2015, at 3:27 PM, bch wrote: Hi there, > > Sure, but: fossil is distinct from the filesystems. DOS, ext, ffs, > > etc., etc., etc are not versioning/managment filesystems, and there > > ought to be a principle-of-least-surprise/being-a-good-citizen kept in > > mind. > > The principle of least surprise says that Fossil should behave like other > VCSes. I think that the principle of least surprise for users of fossil is that the next version of fossil should be pretty much "the same as the current version, only better". I think that the principle of least surprise for non-users of fossil is (much) less important. I think that the last few times this topic came up on the list, there was not a clear enough consensus that changing some fossil commands to do something (potentially) destructive which they are explicitly documented not to do, that the patches were not accepted. Perhaps this time it will be different. For what it's worth, I do think that it would be useful to have a command to affect both the repository and the filesystem in similar ways. But I also think that historical baggage suggests that "rm" (or "mv") is not that command. The matrix in the "hg remove" documentation does cover many (possibly all?) cases. Perhaps a "fossil remove" command could act just like it? With a "fossil move" command to do "fossil mv + suitable filesystem manipulations"? (I confess that I'm not clear on exactly how (or whether) "undo" or "revert" will become involved in the new remove-from-repository-and-filesystem command/argument. I think I didn't understand it the last time around, either.) But one thing I know, is that I won't be the one writing the patches, or deciding whether they go into stock-fossil. Cheers, f -- Francis Dalyfran...@daoine.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] blocking/unencryted content with HTTPS
On Tue, Feb 10, 2015 at 10:50:24PM +0100, Gour wrote: > Francis Daly writes: Hi there, > > So presumably all that is needed is to use the fossil-cgi equivalent > > to fossil-http's "--https" argument. > > My site is set to use https-only, so to me it seems it's still the > original question how to move from HTTP to HTTPS scheme. I suggest the question is simpler: how do you use fossil-cgi behind a https server? I do not see the case covered on https://www.fossil-scm.org/xfer/doc/trunk/www/server.wiki or https://www.fossil-scm.org/xfer/doc/trunk/www/ssl.wiki other than an indication that it Just Works. (And since that server is running https, and is running as cgi, clearly it *does* Just Work. But also clearly, it does not Just Work for you. So either there's stale config in place, or some other difference in how things are set up.) It may be the case that https should be auto-noticed by fossil (by an environment variable, perhaps); if that is so, then you will want to identify why it fails in your case. It may be the case that you must configure fossil to know that it is behind a https server. "--https" was added to "fossil http" to handle it for that command. "baseurl" was added to "fossil cgi" if your local-part of the url is not what fossil would expect; that works for http and https, but not for the / url. I don't see an explicit configuration option available. I suspect that fossil Just Works if the cgi-server puts "HTTPS=on" into the environment; and I guess that your web server does not do that. Can you run a separate cgi script with content like == #!/bin/sh echo Content-Type: text/plain echo /bin/env == and see what comes out? (Unless someone who knows better can make a better suggestion, of course.) f -- Francis Dalyfran...@daoine.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] blocking/unencryted content with HTTPS
On Tue, Feb 10, 2015 at 05:15:39PM +0100, Stephan Beal wrote: > On Tue, Feb 10, 2015 at 5:12 PM, Gour wrote: Hi there, > > When I visit Fossil site via https I see everything is fine, so I wonder > > what do I miss? > If you can tell us which links are still being generated with "http://"; > this can likely be resolved quickly. It looks like it is the https://fossil.atmarama.net/repo.cgi/index) So presumably all that is needed is to use the fossil-cgi equivalent to fossil-http's "--https" argument. Or else, if there is an environment variable that fossil-cgi uses to know "it's really https", the web server could be configured to send that. f -- Francis Dalyfran...@daoine.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] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 02:19:09PM -0600, Andy Bradford wrote: > Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: Hi there, > Perhaps this should really be something like the following? > > > html "" > > > This results in the following output: > > $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: > localhost:8080\r\n\r\n' | nc localhost 8080 | grep base > The "slash to %2F" encoding there is wrong, unfortunately. If file.wiki is served as html and includes a relative link -- such as in "img src=a.png", then that base href should have the browser requesting http://localhost:8080/a.png instead of the (probably intended) http://localhost:8080/doc/tip/a.png. HTML can be fiddly, even if you pretend that all browsers handle things correctly :-( f -- Francis Dalyfran...@daoine.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] FYI: doc URLs don't work with filenames that have + in their names
On Wed, May 28, 2014 at 01:08:26AM +, Joe Prostko wrote:
> On Tue, May 27, 2014 at 11:31 PM, Warren Young wrote:
Hi there,
> > 1. You don't need to do regex matching on the URL here. This does the same
> > thing more efficiently and more clearly:
> >
> > location /demo_project/ {
> I always write this as:
>
> location ~ ^/demo_project {
>
> myself. That way, it's a case-sensitive search where I don't have to
> worry about the trailing slash, and it stops searching once it finds
> /demo_project. I could be mistaken though, but I thought the way you
> suggested wouldn't be as flexible.
This is nginx-config information now, and useful if someone wants to
use nginx as a reverse proxy for fossil. That's the (tenuous) link for
me putting it on this list...
The "location" lines above -- and the ones in the fossil documentation --
are all mostly equivalent if they are the only "location" blocks in the
config. ("mostly" would be "exactly" if they all ended with or without
the slash.)
Where they differ is if there is another "location" line, such as
"location ~ php". In that case, if you request /demo_project/dir/file.php,
which "location" is used will depend on other things.
The "proper" nginx way would be to write it as two separate locations:
location = /demo_project {return 301 /demo_project/;}
location ^~ /demo_project/ { # all the rest }
although there is magic within nginx to make the first location
unnecessary in this case.
So: leave the fossil documentation as-is and expect that anyone actually
using nginx will have read the nginx documentation to properly integrate
the working example into their config if they are doing something more
complicated; or change the fossil documentation to include the "^~"
and make it look less obvious to anyone not using nginx.
Either works; what is there currently is not incorrect.
f
--
Francis Dalyfran...@daoine.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] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 03:46:30PM -0400, Richard Hipp wrote: > On Tue, May 27, 2014 at 3:43 PM, Warren Young wrote: Hi there, > > I had a file called README-Visual-C++.txt in one of my repositories and > > wanted to link to the tip version of it from an outside web page. I > > discovered the "doc URL" feature in Fossil, but it didn't work with that > > file. Apparently there's some kind of data sanitization going on here that > > turns the +'s into spaces. > I think that's an HTTP thing. In a URL, spaces are encoded as "+". So > fossil is doing the right thing in converting "+" characters in the URL > into spaces. Strictly, space is only encoded as "+" in the QUERY_STRING part of a URL. So fossil is incorrect to convert + to space if it is before the first ? in the URL. It's an edge case, but it turns out that someone has hit it. > If the filename really does contain "+" symbols, then the URL should have > "%2b" for each plus. ex: > http://localhost/doc/trunk/README-Visual-C%2b%2b.txt That's a valid encoding, but not a required one (outside of fossil). You could also validly encode the C as %43 and the . as %2e or %2E, and everything should continue to work. (But that usually isn't done.) The no-code-change answer is just to document that fossil requires that + be encoded as %2b everywhere in a URL, but that's probably not a great long-term option. f -- Francis Dalyfran...@daoine.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] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 01:40:28PM -0400, Richard Hipp wrote:
Hi there,
> The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or
> PATH_INFO. CGI should always supply PATH_INFO. SCGI should give us
> REQUEST_URI. Either way, Fossil will be happy now.
CGI only requires SCRIPT_NAME.
If PATH_INFO would be non-empty, then it should be set for CGI. But an
empty PATH_INFO and an absent PATH_INFO are equivalent.
(And in that case, I guess that REQUEST_URI should have the same value
as SCRIPT_NAME, if REQUEST_URI is wanted.)
I think thttpd only sets PATH_INFO when non-empty. It sets SCRIPT_NAME,
but not REQUEST_URI.
f
--
Francis Dalyfran...@daoine.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] Run fossil behind stunnel?
On Fri, Oct 04, 2013 at 02:58:09PM +0200, Jakob Eriksson wrote: Hi there, > How do I run fossil behind stunnel? fossil http --https > and there is a BASE tag in the html which points to: > > http://www.myhost.com:779/login"; /> > > This does not look right, no https, Correct. stunnel and inetd take care of the network side of things, and fossil just speaks http on stdin and stdout. So it must be told if anything "unusual" is in use; and in this context, https is unusual. > Certainly, putting SSL on Fossil is NOT as simple as "just drop it behind > stunnel" as implied > on the web page. Could you provide a link to the web page? Perhaps someone on the list will have access to edit it to be more clear or correct, for the next person. > Could not find any config option inside fossil UI either > which seemed to make any difference. fossil http --help, or http://www.fossil-scm.org/xfer/help?cmd=http, is the documentation, although it may not be clear enough if you don't already know the answer. Cheers, f -- Francis Dalyfran...@daoine.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] Location http://https://domain bug?
On Sat, Jun 29, 2013 at 01:57:39PM -0600, Andy Bradford wrote: Hi there, > My current iteration is using tcpserver (inetd replacement) and stunnel. > Stunnel's configuration is: > > cert = ./test.pem > exec = /tmp/fossil-src-20130618210923/fossil > execargs = fossil http /tmp/test.fossil This says "run fossil http, and it should assume that any generated self-links should be to http:// urls". Add "--https" for generated self-links to be to https:// urls. (fossil help http) > But when I try to use a browser to access it, it fails. This is because > it is sending an invalid Location header (and redirection). Can you show the invalid Location header that it is sending? I guess that it will be http://(whatever Host: header your client sent); which will be invalid because there is not a http listener at that location. > Here is what I see when talking to it myself: > > $ openssl s_client -connect fossil:1621 > > CONNECTED(0003) > ... [trimmed] > GET / HTTP/1.1 > Host: https://fossil:1621 What happens if you just send GET / HTTP/1.0 Host: fossil:1621 ? The important change there is that "http://"; or "https://"; does not appear in the Host: header. > Location: http://https://fossil:1621/index fossil uses your Host: header, adds "http://"; (or "https://";) at the start, and (in this case) /index at the end. That should be correct behaviour, if you use the right Host: header (which your browser should be sending) and (in your case) the --https argument to "fossil http". > This trips up my browser (FireFox). Is this a bug? My Firefox doesn't send "https://"; in the Host header. > So, I thought I would try it with the --baseurl option, but that too is > fraught with other problems. --baseurl does have its uses, but I suspect that "--https" may be all you need to get over the first hurdle. There may well be a second hurdle after that, of course ;-) Cheers, f -- Francis Dalyfran...@daoine.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] CGI mode with multiple repositories
On Tue, Jun 04, 2013 at 03:49:58PM +, org.fossil-scm.fossil-us...@io7m.com
wrote:
Hi there,
> Gitweb handles this by having the user
> actually edit the gitweb script, but I'm not sure where this
> configurable value should go in Fossil.
Create /var/fossil/index.fossil where the front web page is the
editable-to-some list of the repos to make easily visible.
fossil server --notfound /index /var/fossil
Manual updates needed; anything not listed is still accessible if the name
is known; but it is a cheap way of making a friendly list available.
Too naive?
f
--
Francis Dalyfran...@daoine.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] Possible future "fossil rm" behaviour
On Fri, Dec 14, 2012 at 07:58:03PM +, Francis Daly wrote: Hi there, I forgot at least one case, which I can shoe-horn in here by adding: what would be different if "rm a" were added just before "fossil new-rm a", as in: > echo X >a; echo X >b; echo X >c; > fossil add a b > fossil commit -m "a and b = X" > echo Y >b; echo Y >c; rm a > fossil new-rm a > fossil new-rm b > fossil new-rm c > fossil commit -m "all gone" Thanks, f -- Francis Dalyfran...@daoine.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] Possible future "fossil rm" behaviour
Hi there, there is another thread happening which is suggesting or proposing a future version of "fossil rm" which is not identical to the current one. What is the specific desired future behaviour? I think there are three possible future commands to be considered -- whether implemented as commands or as arguments is not of concern here. repo-only-rm -- mark as "not part of the project" repo-and-file-rm -- repo-only-rm, plus remove from the filesystem if safe repo-and-file-really-rm -- repo-only-rm, plus remove from the filesystem if possible Have I missed, or mischaracterised, any? (file-only-rm presumably remains outside of the fossil tool.) Currently, "repo-only-rm" is spelled "rm"; and the other two do not exist within fossil, so to achieve them one must use external scripting which reimplements at least part of the fossil logic to determine which files is a subdirectory should be considered. Avoiding the need to reimplement that logic is probably a good thing. Consider a straightforward case; files only (no directories) and nothing in ignore-glob: echo X >a; echo X >b; echo X >c; fossil add a b fossil commit -m "a and b = X" echo Y >b; echo Y >c; fossil new-rm a fossil new-rm b fossil new-rm c fossil commit -m "all gone" What is the intended behaviour of each of the new-rm commands here? Which, if any, of the new-rm commands fail? If commands fail, what advice is given on how to make them succeed? What files exist in the filesystem after them? If files are gone, is there some way I can recover the "Y" for b and c? Thanks, f -- Francis Dalyfran...@daoine.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 1.23
On Sat, Aug 25, 2012 at 01:47:44AM -0600, Scott Robison wrote: Hi there, > 2. I am color blind. The color coding of bullet points in the "Edit User" > pages explaining which marks indicate what is practically worthless to me I think that is, "fossil ui" in an open checkout, then in the browser click Admin, Users, then the specific User ID, to get to a url very like http://localhost:8080/setup_uedit?id=1 > Some obvious alternatives that > pop into my head are to use multiple bullet shapes instead of just color > coding the same shape or to use subscript or superscript digits or some > such. If it's the page mentioned above, then the source code is in src/setup.c. Look for the word "ueditInheritDeveloper" (in two places) and change "•" after it to, say, "◊ " in the first place, and "◊" in the second. (There's an extra space in the first one, to make it display clearer.) Then do something very similar for ueditInheritReader, ueditInheritAnonymous, and ueditInheritNobody -- perhaps "†", "‡", and leave the other one as "•"? Then rebuild and test that the changes (a) break nothing; and (b) improve something. And then use that as your version of fossil. > 3. I would be happy to take a stab at modifying the source to implement the > stuff above, and I understand there is some sort of copyright assignment or > waiver form to be filled out... You can do what you like with your version of the code. The copyright form is for when you wish to have your changes included in the main repository. And the specific change above is a local display one, so you can get the benefit today and worry about the paperwork later ;-) Cheers, f -- Francis Dalyfran...@daoine.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] Update of checkout after push operations.
On Thu, Jun 14, 2012 at 07:27:26AM +0300, John Found wrote: Hi there, > I wrote the following bash CGI script in attempt to achieve this goal. > For a test I replaced "update" command with "ls" in hope to get as a result > the list of the fossil files. > --- > #!/bin/bash > echo "Content-type: text/html" > echo "" > echo "" > echo "Update the site from the repository." > echo "" > echo "" > > /usr/bin/env > > /usr/local/bin/fossil ls > echo "" > echo "" > echo "" > - CGI programs typically run is a restricted environment. Instead of "env", run "set", which should show you all of your shell variables -- including things like $USER and $UID. (But run that "set" only from a client you trust; you probably don't want to expose the details to the world without checking them first.) If you run fossil as one user in a checkout directory of another user, you may get the "fossil: not within an open checkout" message if the running user lacks the necessary access permissions. >From the rest of the thread, that's my guess as to why you see unexpected behaviour. The complete suggested test cgi script is: == #!/bin/bash echo Content-type: text/plain echo set === and look for anything there that says "this user is not the user you thought it was". (Perhaps compare the output with the output of "set" from your console where things are working as expected.) Good luck with it, f -- Francis Dalyfran...@daoine.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
