Re: [fossil-users] Thoughts about the Custom Pages feature
Hi Stephan and List, You posted some good ideas and took on the difficult job of beginning the development spec. The Münich event addressed some of the points you consider below. As you remember the event occasionally split into groups and Richard took the time to discuss and clarify a few of the points below in a small group. For 1). Another migration path that natively supports this method is the source documentation method used by SQLite. As you know; SQLite documentation is written in the c sources and Tcl scripts pull it into the finished documentation form. These docs and scripts are available on the docs respository. Generating source documentation would be an alternative to 1). Richard was kind enough in one of these small groups to outline the basics of this system. I noted the originating files and could forward it if desired. 2) Custom pages serve output in one of the following forms: If TH1 is not powerful enough for this case (i don't know if it is or isn't, or if it is easy enough to extend), the next obvious choice would be the TCL support (which is, AFAIK, still living in its own branch?). For 2) Joe Mistachkin's previous answer in this thread simplifies these considerations. According to the information given at the Munich Event enabling Tcl will either enable the system Tcl or the abbreviated, small footprint version Jim. Link: Jim Tcl Jim Home http://jim.tcl.tk/index.html/doc/www/www/index.html . These options can provide the needed scripting support. Tcl also offers a possible alternative to jquery. tDom http http://wiki.tcl.tk/http://tdom.github.com/ contains XPath which queries the Dom and parse Html. I also agree that Tcl use should be pursued. - Gary Gabriel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] feature request: commit option to close merged leaf
Hiho, i've come across the twice the past couple days: - merge something from branch foo to trunk. - edit branch foo and close it. Could fossil's infrastructure support the ability (via an option) to close a merged-in leaf on successful commit after a merge? e.g. fossil merge foo trunk fossil commit -m '...' --close-parents which would then close all non-primary parents (most often just one). :-? -- - 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] Thoughts about the Custom Pages feature
On 2012-07-07 13:04, Gary_Gabriel wrote: Hi Stephan and List, You posted some good ideas and took on the difficult job of beginning the development spec. The Münich event addressed some of the points you consider below. As you remember the event occasionally split into groups and Richard took the time to discuss and clarify a few of the points below in a small group. For 1). Another migration path that natively supports this method is the source documentation method used by SQLite. As you know; SQLite documentation is written in the c sources and Tcl scripts pull it into the finished documentation form. These docs and scripts are available on the docs respository. Generating source documentation would be an alternative to 1). Richard was kind enough in one of these small groups to outline the basics of this system. I noted the originating files and could forward it if desired. 2) Custom pages serve output in one of the following forms: If TH1 is not powerful enough for this case (i don't know if it is or isn't, or if it is easy enough to extend), the next obvious choice would be the TCL support (which is, AFAIK, still living in its own branch?). For 2) Joe Mistachkin's previous answer in this thread simplifies these considerations. According to the information given at the Munich Event enabling Tcl will either enable the system Tcl or the abbreviated, small footprint version Jim. Link: Jim Tcl Jim Home http://jim.tcl.tk/index.html/doc/www/www/index.html [1] . These options can provide the needed scripting support. Tcl also offers a possible alternative to jquery. tDom http [2]://tdom.github.com/ contains XPath which queries the Dom and parse Html. I also agree that Tcl use should be pursued. - Gary Gabriel Links: -- [1] http://jim.tcl.tk/index.html/doc/www/www/index.html [2] http://wiki.tcl.tk/http What is essential to understand in the consideration between TCL and Jquery is that * TCl is a server side language * jQeury(javascript) is a client side (browser) language I think it is * not a tcl or jquery(=javascript) question * more a tcl and jquery question * or you could go for javascript as server and client language, well you could have if we started with that language. * going al the way with tcl(also on the client side) seems to fight against the direction where most projects are moving to (e.g. more javascript). It will be much effort to get tcl at a level where it can compete with javascript (facilities) on the client side. -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
