Re: [fossil-users] Markdown
El 29/05/2013 06:28, Jonathan Otsuka djg...@gmail.com escribió: Downloads are not compiled with --markdown (its still experimental) you will need to checkout and compile fossil with --markdown yourself. Beware that --mardown is not a configure option anymore, in trunk, so it will be enabled by default in future releases. Jonathan Otsuka On May 28, 2013, at 10:29 PM, Doug Franklin nutdriverle...@comcast.net wrote: Do the default (downloadable) versions of Fossil not have Markdown support enabled, or am I doing something wrong? My browser keeps telling me open or save this unknown file type. -- Thanks, DougF (KG4LMZ) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How to set-up multiple-repo CGI-based server?
I am struggling to see what is tripping me up when a single repository works fine, but multiple repositories within a directory fails as follows: https://mail.google.com/mail/ca/u/0/#inbox $ cat repo.cgi #!/home/sites/my.domain/bin/fossil repository: /home/sites/my.domain/repos http://my.domain/cgi-bin/repo.cgi/repo1 SQLITE_CANTOPEN: cannot open file at line 28175 of [7e10a62d0e] SQLITE_CANTOPEN: os_unix.c:28175: (21) open(/home/sites/my.domain/repos) - Is a directory Database Error [/home/sites/my.domain/repos]: unable to open database file ... The following edit serves a single repository without error: $ cat repo.cgi #!/home/sites/my.domain/bin/fossil repository: /home/sites/my.domain/repos/repo1.fossil Some environment data from the server gives me no clue: $ cat bash-test.cgi #!/bin/bash echo Content-Type: text/plain env | sort DOCUMENT_ROOT=/home/sites/my.domain/public_html/ GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_ENCODING=gzip, deflate HTTP_ACCEPT_LANGUAGE=en-gb,en;q=0.5 HTTP_CONNECTION=keep-alive HTTP_HOST=my.domain HTTP_USER_AGENT=Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0 PATH=/usr/local/bin:/usr/bin:/bin PWD=/home/sites/my.domain/cgi-bin QUERY_STRING= REMOTE_ADDR=my.ip.61.0 REMOTE_PORT=22428 REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/bash-test.cgi SCRIPT_FILENAME=/home/sites/my.domain/cgi-bin/bash-test.cgi SCRIPT_NAME=/cgi-bin/bash-test.cgi SCRIPT_URI=http://my.domain/cgi-bin/bash-test.cgi SCRIPT_URL=/cgi-bin/bash-test.cgi SERVER_ADDR=79.170.44.123 SERVER_ADMIN=webmaster@my.domain SERVER_NAME=my.domain SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=addressApache/2 Server at my.domain Port 80/address SERVER_SOFTWARE=Apache/2 SHLVL=1 _=/usr/bin/env $ fossil version This is fossil version 1.25 [d2e07756d9] 2013-02-16 00:04:35 UTC A further test on my local machine gives me: $ cat test.cgi #!/usr/bin/fossil repository: /home/nrb/987mb nrb@nrb-ThinkPad-T61:~$ fossil cgi test.cgi Status: 200 OK X-Frame-Options: SAMEORIGIN Cache-control: no-cache Content-Type: text/html; charset=utf-8 Content-Length: 433 p class=generalError SQLITE_CANTOPEN: cannot open file at line 28175 of [7e10a62d0e] /p p class=generalError SQLITE_CANTOPEN: os_unix.c:28175: (21) open(/home/nrb/987mb) - Is a directory /p h1Database Error/h1 pre[/home/nrb/987mb]: unable to open database file/pre pIf you have recently updated your fossil executable, you might need to run fossil all rebuild to bring the repository schemas up to date. /p Experimenting with a notfound: /repo1 does not change behaviour. Any help would be much appreciated! BR/ Nigel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set-up multiple-repo CGI-based server?
On Wed, May 29, 2013 at 6:11 PM, Nigel Bray fossil@9ox.net wrote: I am struggling to see what is tripping me up when a single repository works fine, but multiple repositories within a directory fails as follows: https://mail.google.com/mail/ca/u/0/#inbox $ cat repo.cgi #!/home/sites/my.domain/bin/fossil repository: /home/sites/my.domain/repos See the section Serving multiple repositories with one script in http://www.fossil-scm.org/xfer/doc/trunk/www/server.wiki In short, you need something like: #!/home/sites/my.domain/bin/fossil directory: /home/sites/my.domain/repos notfound: http://url.to/your/favorite/404page.html Hope this helps. -- MIURA Masahiro echocham...@gmail.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set-up multiple-repo CGI-based server?
On Wed, May 29, 2013 at 5:22 AM, MIURA Masahiro echocham...@gmail.comwrote: On Wed, May 29, 2013 at 6:11 PM, Nigel Bray fossil@9ox.net wrote: I am struggling to see what is tripping me up when a single repository works fine, but multiple repositories within a directory fails as follows: https://mail.google.com/mail/ca/u/0/#inbox $ cat repo.cgi #!/home/sites/my.domain/bin/fossil repository: /home/sites/my.domain/repos See the section Serving multiple repositories with one script in http://www.fossil-scm.org/xfer/doc/trunk/www/server.wiki In short, you need something like: #!/home/sites/my.domain/bin/fossil directory: /home/sites/my.domain/repos notfound: http://url.to/your/favorite/404page.html I think Miura is correct. But just to clarify - the key change is to replace repository: with directory:. The notfound: line is useful, but not required, iirc. -- 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] 2 possible bugs?
Hi, revising fossil code with clan analyzer, 2 possible bugs where found, from
last trunk ( 4175c90f9522299c07ae4da5d19b93a50ce5f74c
http://www.fossil-scm.org/xfer/info/4175c90f95):
a) src/file.c line 197-201
197 if( zName!=zBuf ) free(zName);
if( symlink(zTargetFile, zName)!=0 ){
fossil_fatal_recursive(unable to create symlink \%s\, zName);
201 }
So zName may be used after free.
b) src/attach.c line 490
490 free(zDate);
@ trthUser:/thtd
492 hyperlink_to_user(pAttach-zUser, zDate, /td/tr);
Similar, zDate is used after the free.
HTH
--- ---
Eduardo Morras emorr...@yahoo.es
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set-up multiple-repo CGI-based server? (fossil: d...@sqlite.org exclusive)
On 29 May 2013 11:12, Richard Hipp - d...@sqlite.org fossil.nrb.4c1d029458.drh#sqlite@ob.0sg.net wrote: On Wed, May 29, 2013 at 5:22 AM, MIURA Masahiro echocham...@gmail.com wrote: On Wed, May 29, 2013 at 6:11 PM, Nigel Bray fossil@9ox.net wrote: I am struggling to see what is tripping me up when a single repository works fine, but multiple repositories within a directory fails as follows: See the section Serving multiple repositories with one script in http://www.fossil-scm.org/xfer/doc/trunk/www/server.wiki In short, you need something like: #!/home/sites/my.domain/bin/fossil directory: /home/sites/my.domain/repos notfound: http://url.to/your/favorite/404page.html I think Miura is correct. But just to clarify - the key change is to replace repository: with directory:. The notfound: line is useful, but not required, iirc. -- D. Richard Hipp d...@sqlite.org Many thanks Miura and Richard, that works! Sorry for missing the obvious, but really pleased to be up and running again having moved a few times from my own local inetd/althtpd[1] to Chisel/flint[2] then dropbox and now on my webhost using their ssh access. Despite my error, I find the simplicity of setting up a Fossil repo (or better a set of repos) under cgi fantastic. BR/ Nigel [1] althttpd, http://www.sqlite.org/docsrc/artifact/14c9965da19?ln=2-62, so valuable and a bit hard to search for I dug out the link [2] chisel and flint, http://chiselapp.com/repositories/search/flint, also excellent, and thanks to James and Rkeene for latest changes ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set-up multiple-repo CGI-based server? (fossil: d...@sqlite.org exclusive)
On Wed, May 29, 2013 at 3:59 PM, fossil@9ox.net wrote: Despite my error, I find the simplicity of setting up a Fossil repo (or better a set of repos) under cgi fantastic. +1 @Richard: out of historical interest, what was the motivation behind adding CGI support initially? (Despite CGI being archaic, it was _the_ feature which caused my initial addiction to fossil.) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] 2 possible bugs?
On Wed, May 29, 2013 at 3:57 PM, Eduardo Morras emorr...@yahoo.es wrote: a) src/file.c line 197-201 b) src/attach.c line 490 Man, he's fast - i was about to commit these fixes, but Richard beat me to it: http://www.fossil-scm.org/xfer/info/04ab1af3e0 Thanks for the report! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Chiselapp.com shutting down
NB: Apologies if I don't get this to thread correctly, I've not got an email copy of the original post, so can't reply properly. As an occasional Fossil user, I have previously hosted using inetd/althttpd[1] and Chisel[2] as well as Dropbox. Now I have moved to cgi, given ssh access, it seems to be as simple as just three file copies, right? scp fossil user@webservers-ssh-domain:/path-to-host's-executables/bin/ ## if binary not available for host machine, then instead, do wget of the sources and ./configure make on the host scp repos.cgi user@webservers-ssh-domain:/path-to-host's-scripts/cgi-bin/ scp repo1.fossil user@webservers-ssh-domain:/path-to-host's-repositories/repos/ # repeat the above copy for more than one repository on the server # backup the original copied fossil archives from the client machine, and 'fossil clone' new copies from the server (fossils can be moved, but I think should not be duplicated, internals of fossil need state variables dependent upon the instance) A further thread I found very valuable is the knowledge that this can be done on sourceforge for open source projects [3]. I use fossil to share data with people who are normally dropbox users for their personal use and occasional users of corporate VCS/tracking tools. I and people I introduce Fossil to feel that it is an excellent model of elegant design and efficient workflow and would like to see it adopted more widely, and perhaps bring in extra valuable contributors. I find that the idea of hosting [4] is great and that for me; an additional facility matching dropbox background file syncing could perhaps widen the user base. A client(Fossil) installed like that for dropbox[5] on the users local machine would be most handy. As Fossil already does autosync and autocheckout, some extra client side automatic checkin and filename splitting on (rare) replication conflicts may be needed to match dropbox usability. On top of a Fossil hosting service, this wish I have, could be characterised as anybody who wants to use fossil like dropbox simply has to download the client package, open to install it, agree to let it start on reboot and run in the background. Given an available hosting solution, the user would see something like: If you're running this for the first time, you'll be asked to create a new account or add this to an existing account. Once you do, your Fossil folder will be created in your home directory. [1] althttpd, http://www.sqlite.org/docsrc/artifact/14c9965da19?ln=2-62 [2] chisel and flint, http://chiselapp.com/repositories/search/flint [3] ssh access to sourceforge, http://thread.gmane.org/gmane.comp.version-control.fossil-scm.user/12163, really convenient option for self hosting open source [4] fossil hosting requirements, http://thread.gmane.org/gmane.comp.version-control.fossil-scm.user/12160/focus=12167, anybody who wants to host something like chiselapp simply has to obtain a low-cost internet host, copy the fossil executable into /usr/bin, create a single CGI script that is less than 10 lines long, and they are up and running [5] dropbox client application, https://www.dropbox.com/help/247/en, seems to have wide adoption ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to set-up multiple-repo CGI-based server? (fossil: d...@sqlite.org exclusive)
On Wed, May 29, 2013 at 10:09 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, May 29, 2013 at 3:59 PM, fossil@9ox.net wrote: Despite my error, I find the simplicity of setting up a Fossil repo (or better a set of repos) under cgi fantastic. +1 @Richard: out of historical interest, what was the motivation behind adding CGI support initially? (Despite CGI being archaic, it was _the_ feature which caused my initial addiction to fossil.) Well, I suppose I don't consider CGI to be archaic. CGI is simple, concise, easy to administer, easy to implement (on both ends), efficient, and is supported by all web-servers (except nginx). CGI grows out of the historic development model where you spin up a new process to handle each specific task. Unix was built around this model. It is an older model, but just because it is old doesn't make it bad. There is really quite a lot to recommend it: (1) No need to worry about resource leaks because the operating-system automatically and efficiently reclaims resources when the short-lived working process dies. (2) Programming is much simpler because you can almost always run single-threaded and you can often get away with using global variables. (3) Unit testing and debugging is easier since the worker task is now an independent process that can be run from a command-line prompt and/or in gdb or valgrind. (4) Bugs in the application are well-contained. One worker task might segfault due to a bug, but other independent tasks continue happily running without impact. (5) There are no background processes that an administrator needs to monitor and keep running. The worker tasks are launched on-demand. Thus the administrative overhead is reduced. I'm not sure why the one-process-per-task model has fallen out of favor. One cause might be a quest to squeeze every last ounce of performance out of systems by avoiding the process creation and breakdown overhead. Another reason might be people growing up in a windows-oriented world where process creation and breakdown is significantly more complex and costly compared to unix where fork() and exit() are easy and cheap. I like things to have low administrative, development, and maintenance overhead. CGI fits that requirement nicely. Other similar technologies (FCGI or SCGI come first to mind) require a lot more effort to program, to set up, and to maintain. Those others might be slightly faster on a busy site, but CGI is fast enough for most applications, especially for small and light-weight applications. For something like Fossil, FCGI/SCGI would be no faster. (FCGI/SCGI might well be much faster if your CGI script starts with #!/usr/bin/perl or #!/usr/bin/php, but that is a function of the start-up overhead of your scripting language, not of the interprocess communication protocol. Fossil, being native code, starts up very quickly and so CGI startup time is minimized and the performance advantages of FCGI/SCGI are lost in the noise of the added complexity.) The Fossil and SQLite websites spin up about 4 or 5 new worker processes per second on a debian linux VM at Linode.com that is a 1/24th slice of an actual server. And yet the load average stays down around 5%. People say Oh, you could go so much faster using $COOL_NEW_TECHNOLOGY. But I doubt it. And even if we could, with the load average holding steady at 5%, it isn't worth the trouble. Better to keep things simple and reliable. -- 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] How to set-up multiple-repo CGI-based server? (fossil: d...@sqlite.org exclusive)
On Wed, May 29, 2013 at 5:01 PM, Richard Hipp d...@sqlite.org wrote: Well, I suppose I don't consider CGI to be archaic. CGI is simple, concise, easy to administer, easy to implement (on both ends), efficient, and is supported by all web-servers (except nginx). Thank you for the detailed insights. i feel compelled to amend my statement about it being archaic to i _thought_ it was archaic until Fossil showed me otherwise. Since then i've written several CGIs in C and didn't feel the slightest bit archaic while doing so :). The Fossil and SQLite websites spin up about 4 or 5 new worker processes per second on a debian linux VM at Linode.com that is a 1/24th slice of an actual server. And yet the load average stays down around 5%. People say Oh, you could go so much faster using $COOL_NEW_TECHNOLOGY. But I doubt it. And even if we could, with the load average holding steady at 5%, it isn't worth the trouble. Better to keep things simple and reliable. Amen! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Chiselapp.com shutting down
On Wed, May 29, 2013 at 7:37 AM, Nigel Bray fossil@9ox.net wrote: NB: Apologies if I don't get this to thread correctly, I've not got an email copy of the original post, so can't reply properly. As an occasional Fossil user, I have previously hosted using inetd/althttpd[1] and Chisel[2] as well as Dropbox. As a side note, in case you (and/or others) are not aware, Chisel found a new place to live at and is alive and well. The shutdown did not happen. Its url is completely unchanged, only the underlying IP address moved. [2] chisel and flint, http://chiselapp.com/repositories/search/flint -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato Tcl'2013, Sep 23-27, New Orleans, LA, USA @ http://www.tcl.tk/community/tcl2013/ EuroTcl'2013, July 6-7, Munich, GER ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] JSON API docs
What's the current canonical location of documentation for Fossil's JSON API? Are there some handy howtos, tutorials, examples, or other third-party sources of documentation for the JSON API? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] How to set-up multiple-repo CGI-based server? (fossil: d...@sqlite.org exclusive)
Richard, Agree with all you say, it reflects my frustrations about a profession where simple, stable and reliable is so readily dismissed as outdated. Re your specific comment I'm not sure why the one-process-per-task model has fallen out of favor.. It may be because early web servers (and Apache in particular) struggled to scale on the then available hardware. That and (as you mention) the startup cost of the languages being used. Re SCGI, while I agree with all you say my experience is that it isn't difficult at all (at least, from Tcl). In the Einstein Brain Atlas project we use NGINX + SCGI and it works just fine and is relatively simple to integrate with Tcl. Not that I'm advocating SCGI for Fossil, but if you do have needs that go beyond what simple CGI can provide then Nginx/SCGI is a relatively small incremental complexity cost. Steve On 29/05/2013, at 10:01 AM, Richard Hipp d...@sqlite.org wrote: On Wed, May 29, 2013 at 10:09 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, May 29, 2013 at 3:59 PM, fossil@9ox.net wrote: Despite my error, I find the simplicity of setting up a Fossil repo (or better a set of repos) under cgi fantastic. +1 @Richard: out of historical interest, what was the motivation behind adding CGI support initially? (Despite CGI being archaic, it was _the_ feature which caused my initial addiction to fossil.) Well, I suppose I don't consider CGI to be archaic. CGI is simple, concise, easy to administer, easy to implement (on both ends), efficient, and is supported by all web-servers (except nginx). CGI grows out of the historic development model where you spin up a new process to handle each specific task. Unix was built around this model. It is an older model, but just because it is old doesn't make it bad. There is really quite a lot to recommend it: (1) No need to worry about resource leaks because the operating-system automatically and efficiently reclaims resources when the short-lived working process dies. (2) Programming is much simpler because you can almost always run single-threaded and you can often get away with using global variables. (3) Unit testing and debugging is easier since the worker task is now an independent process that can be run from a command-line prompt and/or in gdb or valgrind. (4) Bugs in the application are well-contained. One worker task might segfault due to a bug, but other independent tasks continue happily running without impact. (5) There are no background processes that an administrator needs to monitor and keep running. The worker tasks are launched on-demand. Thus the administrative overhead is reduced. I'm not sure why the one-process-per-task model has fallen out of favor. One cause might be a quest to squeeze every last ounce of performance out of systems by avoiding the process creation and breakdown overhead. Another reason might be people growing up in a windows-oriented world where process creation and breakdown is significantly more complex and costly compared to unix where fork() and exit() are easy and cheap. I like things to have low administrative, development, and maintenance overhead. CGI fits that requirement nicely. Other similar technologies (FCGI or SCGI come first to mind) require a lot more effort to program, to set up, and to maintain. Those others might be slightly faster on a busy site, but CGI is fast enough for most applications, especially for small and light-weight applications. For something like Fossil, FCGI/SCGI would be no faster. (FCGI/SCGI might well be much faster if your CGI script starts with #!/usr/bin/perl or #!/usr/bin/php, but that is a function of the start-up overhead of your scripting language, not of the interprocess communication protocol. Fossil, being native code, starts up very quickly and so CGI startup time is minimized and the performance advantages of FCGI/SCGI are lost in the noise of the added complexity.) The Fossil and SQLite websites spin up about 4 or 5 new worker processes per second on a debian linux VM at Linode.com that is a 1/24th slice of an actual server. And yet the load average stays down around 5%. People say Oh, you could go so much faster using $COOL_NEW_TECHNOLOGY. But I doubt it. And even if we could, with the load average holding steady at 5%, it isn't worth the trouble. Better to keep things simple and reliable. -- 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] Did you know that Fossil could do...
On Tue, May 28, 2013 at 09:08:10AM -0400, Richard Hipp wrote: Survey: How many people know that in the web-based timeline for Fossil, you can click on any two nodes in the graph and get a diff between those two nodes? I think this is a very useful feature. But I'm guessing that not many people know it exists. Please confirm or refute my guess. And assuming I'm guessing correctly, do you have any suggestions on how I can get the word out about this and other useful but obscure features of Fossil? Maybe this will help a little bit: https://twitter.com/CopyfreeNews/status/339811545045417984 -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Handling renames on import
Replying Richard Hipp: On Mon, May 27, 2013 at 3:35 PM, Isaac Jurado dipto...@gmail.com wrote: Hello, I'm testing Fossil by migrating a bunch of Mercurial repositories. Unlike Git, Mercurial tracks file renames. However, in order to create a Fossil repository I have to follow the Mercurial - Git - Fossil path. On the first conversion I lose file copying/renaming information. But the git fast-export command has the -M and -C switches to enable copy/rename detection heuristics. Therefore, the last conversion step looks like: git fast-export -M -C --all | fossil import --git ../myrepo.fossil The good news is that the heuristics work, as Fossil fails with the following message: cannot handle R records, use --full-tree Do you have a git-fast-export output file that you can send me for testing purposes (perhaps via private email)? Well, I've been digging around a bit. After reading the git-fast-import man page and doing some experiments, I've discovered the following: The R record has exactly the same syntax as the C record. Therefore, for each file that has been renamed there is a commit record like: R old_name new_name If, apart from a rename, there were changes in the file contents, an additional M record is appended just below the rename. I'm not really sure about the value and support of file rename in Fossil for three reasons: 1. There is no copy command 2. The mv/rename command does not actually operate on the filesystem, but after the user has performed the operation 3. This mail: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-July/000325.html I'm willing to carry on and try to fix this missing import piece, but only if it is worth the trouble. Does mv/rename improve the delta algorithm and/or file tracking in any way? Regards. -- Isaac Jurado The noblest pleasure is the joy of understanding. Leonardo da Vinci ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON API docs
On Wed, May 29, 2013 at 7:41 PM, Chad Perrin c...@apotheon.net wrote: What's the current canonical location of documentation for Fossil's JSON API? Are there some handy howtos, tutorials, examples, or other third-party sources of documentation for the JSON API? Hi, Chad! The current location of the API docs, updated as the code is updated: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view (Requires a gmail account, if i'm not mistaken.) i happily accept new contributors - just send me your gmail account name and i'll gladly add you to the list. Examples... i don't really have any hello world examples, but i do have examples of its usage: 1) in the source tree: ajax/i-test/rhino-test.js uses the JSON API via the Rhino JavaScript VM. You can run it using the Rhino VM by starting a local fossil server on port 8080 and then: js rhino-test.js 2) http://fossil.wanderinghorse.net/wikis/cpdo/ that is a fossil-backed wiki with a completely custom front-end implemented using the JSON API. The code for that front-end is here: http://fossil.wanderinghorse.net/repos/fwiki/ Feedback on the JSON API and the docs is happily received, and don't hesitate to ask questions about it. The docs are relatively comprehensive (over 50 pages) but there might holes and there are certainly some APIs which have very debatable interfaces - feel free to debate them. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON API docs
On Wed, May 29, 2013 at 10:23 PM, Stephan Beal sgb...@googlemail.comwrote: http://fossil.wanderinghorse.net/repos/fwiki/ These demos of that code are good starting points to see what the JSON API can do: http://fossil.wanderinghorse.net/repos/fwiki/editor/wiki-editor-goco.html http://fossil.wanderinghorse.net/repos/fwiki/editor/wiki-editor.html http://fossil.wanderinghorse.net/repos/fwiki/editor/fijet-scratchpad.html IIRC those pages demonstrate more or less all of the JSON API features. Be sure to turn on your browser's dev tools (Firebug or Chrome Dev Tools or whatever) and watch the JSON traffic. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] JSON API docs
On Wed, May 29, 2013 at 10:23:50PM +0200, Stephan Beal wrote: On Wed, May 29, 2013 at 7:41 PM, Chad Perrin c...@apotheon.net wrote: What's the current canonical location of documentation for Fossil's JSON API? Are there some handy howtos, tutorials, examples, or other third-party sources of documentation for the JSON API? The current location of the API docs, updated as the code is updated: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view Thanks. For some reason, I had the impression that might be out of date and/or no longer the canonical location. I think I had some vague recollection of the docs being moved to a wiki somewhere from earlier list traffic, but didn't find it in my email archives. I guess I was mistaken. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Handling renames on import
On Wed, May 29, 2013 at 4:22 PM, Isaac Jurado dipto...@gmail.com wrote: Does mv/rename improve the delta algorithm and/or file tracking in any way? Unclear. I think it does, but I'm not 100% sure. Deltas in Fossil are decoupled from the rest of the system. There is no fixed delta schedule. You can create new, completely compatible versions of Fossil that delta differently. So it is certainly possible to create a version of Fossil that takes advantage of mv/rename to improve delta encoding performance. But whether or not the current implementation does so is unclear. Probably best to determine that by experimentation. -- 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] JSON API docs
On Wed, May 29, 2013 at 11:34 PM, Chad Perrin c...@apotheon.net wrote: and/or no longer the canonical location. I think I had some vague recollection of the docs being moved to a wiki somewhere from earlier list traffic, but didn't find it in my email archives. I guess I was mistaken. No, not mistaken, just not up to date - at some point i started porting it into a wiki, but a wiki's structure is forever (or a pain to change) and i didn't find a structure i liked. The remnants of that effort are still around, though, should the muse strike me to try it again. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
