Re: [fossil-users] Repo extension in "fossil cgi" when used with "directory:"
Hi Richard,
ok, understood. I'll try to rename them.
(Local checkouts on that machine itself need to point to the changed file
then as well, so it might be more fallout than renaming)
Thanks for looking at that!
As I had a quick (non-deep) look I thought it is only a matter of making
a static hardcoded string in main.c
db_multi_exec("DELETE FROM sfile WHERE pathname NOT GLOB '*[^/
].fossil'");
configurable. But as it turns out to be non-trivial, please leave it as
it is. I'll change my setup.
Maybe the wiki cookbook recipe should be changed, though, so that it also
uses *.fossil instead of *.fsl or to simply mention that this recipe is
not needed at all anymore.
Thanks
Tino
---
Am Wed, 21 Feb 2018 12:01:55 -0500 schrieb Richard Hipp:
> 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?
___
fossil-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:"
Hi Fossil developers, now that 2.5 is out and settled (thank you!) and the very nice change https://fossil-scm.org/index.html/info/f2231ba6684157db in the very same code region has been done I wonder if my request below could be considered, please? I think this is quite an easy, small change - just making the file extension to search for configurable. Thanks and best regards Tino -- Am Tue, 30 Jan 2018 15:22:54 + schrieb Tino Lange: > Hi! > > One wish for >= 2.5: > > Could you please make the extension of repositories configurable in > "fossil cgi", when used with "directory:"? > > Background: I have been using the recipe: > https://www.fossil-scm.org/xfer/ > wiki?name=Cookbook#CGI (see section "Another solution to automatically > serve multiple repositories") and so I have plenty of "*.fsl" files > already. > > Thanks and best regards, > > Tino > > ___ > 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] Repo extension in "fossil cgi" when used with "directory:"
Hi! One wish for >= 2.5: Could you please make the extension of repositories configurable in "fossil cgi", when used with "directory:"? Background: I have been using the recipe: https://www.fossil-scm.org/xfer/ wiki?name=Cookbook#CGI (see section "Another solution to automatically serve multiple repositories") and so I have plenty of "*.fsl" files already. Thanks and best regards, Tino ___ 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 rm --hard dir1
Hi! When doing a $ fossil rm --hard dir1 it will unregister from fossil and then delete all files within the 'dir1' hierarchy. But: The directory/directories will keep existing! I need to do a $ rm -rf dir1 afterwards (so the whole --hard is mostly needless, since I need to do the additional "rm" anyhow). Could this be fixed, please? At least in this usage scenario above one wants to have no 'dir1' after the fossil operation, or? Thanks and best regards Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil all remove?
> Should be automatic. When you do "fossil all ls -c", Fossil checks that > each of the check-out directories exists, and removes any that do not > exist from the list. Thanks. The directory still exists (but with some other content now, especially it has no .fslckout file) So I'll move it away, do a "fossil all ls -c" and move it afterwards back to its location :-) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil all remove?
Hi Fossilers, There is no "fossil all remove". How can I get rid of an entry in "fossil all ls -c" for which the checkout does not exist anymore? Do I need to fiddle with SQL? Thanks Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Using fossil just for the wiki. Images and tables?
>> [...] Fossil's Markdown support is via libdiscount [...] > [...] Oh, Fossil uses Discount. Thanks, [...] libdiscount? Sure? Isn't that a special version of libsoldout? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] click-to-diff on IE8
Richard Hipp wrote on Fri, 07 Dec 2012 09:38:27 -0500: I do not have access IE8. The oldest windows box I have is running IE9. Hi! ( I know the concrete problem is already fixed. But for the next time ) maybe this link here is helpful: http://www.microsoft.com/en-us/download/details.aspx?id=11575 MS offers free Virtual Machines (run perfectly also in VirtualBox or kvm, not only on MS Virtual PC) with different IE versions. So you can test IE6 - IE9 on different MS platforms for free with that. You can of course as well test or compile fossil.exe on different windows versions with that easily. Cheers Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 1.22: Add the ability to run TH1 scripts after sync requests
Hi! 1.22 ChangeLog: Add the ability to run TH1 scripts after sync requests I'm a bit lost -- where can I find more infrmation about that new feature? Examples? What to do with it? Can I for example use it to have some basic commit hooks? Thanks Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Release version of fossil based on embedded SQLite with alpha status?
It's been a long time since there has been an official release of Fossil. This is Version 1.19. Changes in this release include: [...] - Update to the latest SQLite version 3.7.8 alpha. Hi! An official release with an embedded *alpha* version? Is this really a release version meant for production as 1.18 was? Cheers, Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Keyword Expansion?
Hi List, would it be possible to add a feature like the good old keyword expansion from SVN (in fact even from CVS) to fossil? For scripts there's no possibility to embedd the version or any kind of additional information at the moment. Yes, there is (maybe nowadays...) the manifest and the manifest.uuid to get that information at runtime, but that means distributing those files additionally with each script. fossil and sqlite solve that somehow by being compiled :-) -- they just compile the information from those manifest files in their final executable, but thats not a reasonable approach for scripts that are executed by an interpreter. Here we know the version only when the files stay in their check-out folder, nearby the mainfest files. Something like the svn:keywords for a bunch of reasonable 'variables' would be a very helpful addition IMHO. The feature should be off by default and should be enabled on a per file (and maybe per keyword) basis on demand. (See svn:keywords and/or hg keyword extension for working examples in other version control software) What do you think? Thanks and cheers, Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Keyword Expansion?
Hi Paul,
thanks very much for your quick response.
fossil and sqlite solve that somehow by being compiled :-) -- they just
compile the information from those manifest files in their final
executable, but thats not a reasonable approach for scripts that are
executed by an interpreter.
Actually, both fossil and sqlite use their build interpreter ('make' and
'tcl' respectively) to process the manifest files into source code. What
stops your interpreter from doing the same? It could perform all the
functions you require, perhaps using additional info made available
through the manifest.
Well, usually scripts checked in some version control system are simply
ready to run (executable bit set) as they are and don't require a
'preprocessing' step to generate some kind of executable (in contrast to
C/C++ programs like sqlite and fossil) . The source *is* the executable so
to say.
That means you cannot distribute this executable versioned unless you either
distribute the manifest files altogether with the script or you somehow
change it after checkout/update/commit by some helper scripts to include the
version inside. If you distribute your script to someone else I find it
rather unconvinient to give hime some detached version information like
the manifest files that for sure will be lost, not noticed or not unpacked
properly on the other side.
Of course I can also imagine checking in only some 'skeleton' for the script
and let make or other tools create the real script from this skeleton and
the manifest and whatever on demand as you propose above, but then changes
in the script cannot be done in-place for the next check in. You have to
edit the skeleton and create the script from it each time. It simply adds
two (IMHO unnecessary?) steps in the development workflow if you would like
to have a version embedded in the script. (Note there are also no commit
hooks in fossil to automate that, this would have been another possible
approach)
Personally I've always considered 'in source' markers as a bad hack,
rooted in now ancient tools (SCCS/1972 and RCS/1982). I'm not against the
idea per se, but I would like to understand your requirements better.
Could you elaborate?
I don't like general keyword expansion either, but for the special case
'scripts' (maybe also for easy versioned plain text documents like concepts,
rfcs or similar) it could make sense. That's why it should be a well
configurable optional feature (as for example in mercurial).
Could you elaborate?
Hope this was now understandable enough, please ask if there are still
things unclear.
Thanks
Tino
___
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 and file permissions -- was: Re: Fossil limitation workarounds
Barry Kauler wrote: 4. Fossil does not record permissions and ownerships of files. Tino Lange wrote: Is that true? A quick experiment with a 755 and 644 file, checked in in my working repository, synced to the master repository and checked out at another location from the master showed correct file permissions. But changing permissions after that initial step doesn't seem to change anything. Hi! Anyone knows more here? Is fossil capable of keeping and maintaining file permissions or not? I couldn't find any hint in the documentation/wiki - and the experiments yield ambigous results. Thanks Tino ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
