[fossil-users] general question about multiple source-trees in 1 repo, and recursive diff
Hello, some of the bigger source-projects here consist of multiple applications, docs, and so on. Up to now I have used 1 repo per project (that is, all trees of all applications + docs + whatever into the same repo). I wonder if most of you do it like this as well, or have a finer granularity, with perhaps multiple repos with each having only 1 source-tree belonging to 1 application, or only docs, or only reference-material, and so on. The reason I ask now, is that when doing recursive diff between 2 tags/revisions of an application (say an older one and the current one, checked out on disk already), I checkout the older one in a temporary dir, run the diff of choice, do whatever I want to do, and dthen iscard the checkout of the old revision. Is there a better way to do this..? Alternately, when diff'ing in the fossil web-UI by clicking/selecting the old checkin first, then the head, is there a way to only show Modified files? Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] tree-view of files
Hello, I noticed that when clicking on 'files' in a checkin-summary (e.g. random checkin https://www.fossil-scm.org/index.html/info/f83e0d2123), tree-view is now displayed instead of legacy flat-dir. No complaints here, but was this intentional? (Is 'tree' the new 'dir'..?) Michai ___ 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] tree-view of files
On 6 January 2014 11:59, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I noticed that when clicking on 'files' in a checkin-summary (e.g. random checkin https://www.fossil-scm.org/index.html/info/f83e0d2123), tree-view is now displayed instead of legacy flat-dir. No complaints here, but was this intentional? (Is 'tree' the new 'dir'..?) actually... one obvious drawback is that due to expanding subdirs, the actual 1st-level files/subdirs are now scattered. Is there a way to use 'dir' as default, and 'tree'-view only when explicitly telling it to? (TBH I haven't read all of the tree-view details yet, chances are I missed it or am doing something wrong.) Michai ___ 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] general question about multiple source-trees in 1 repo, and recursive diff
On Mon, Jan 06, 2014 at 09:24:53AM +0100, Michai Ramakers wrote: Hello, [snip] Is there a better way to do this..? Alternately, when diff'ing in the fossil web-UI by clicking/selecting the old checkin first, then the head, is there a way to only show Modified files? I recently merge a small change on trunk with this capability. Right now, you have a button Hide Diff (which mean show list of modified files only) when clicking on 2 commits from timeline. There's also a setting to hide the diff by default if you want. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New Tree-View feature requires newer sqlite.
2014/1/4 Richard Hipp d...@sqlite.org: OK, so I propose the following fix: (1) Move [bd1151126a] into a branch. (2) Remove the --disable-internal-sqlite option on trunk. Require the use of the built-in SQLite only, since SQLite needs to be built with non-standard compile-time options to fully meet the needs of Fossil. (3) Cherry-pick check-ins after [bd1151126a] onto the trunk. (4) When distributions complain, we simply explain that we tried using an external SQLite but it introduced too many complications and bugs and that we now require statically linking SQLite for reasons of security and reliability. Comments? How about this counter-proposal? Explanation follows: (1) Update fossil to require SQLite 3.7.17 as a minimum in stead of the current SQLite 3.7.0. See: http://fossil-scm.org/index.html/timeline?r=sqlite-min-to-3.7.17 (2) Eliminate the strglob() function from fossil, use the sqlite3_strglob() function (available since SQLite 3.7.17) instead. I tested this change: all unit-tests work fine. (3) After SQLite 3.8.3 is released, release fossil 1.28 with the EXACT SQLite 3.8.3 amalgamation included. (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add WITHOUT ROWID to whatever SQL statement it is useful. Unconditionally! (5) Future official fossil release should contain an official released SQLite amagalmation as well, but less frequent: There is no need to make a new Fossil release after each SQLite release. I think this counter-proposal will gain a lot more sympathy to the various package-maintainers. And it has more advantages. Explanation: at (1): Supporting every SQLite 3.7.x release is madness, SQLite 3.7.17 is more than 7 months old now, that should be enough time for whatever distribution to upgrade to it. at (2): Code duplication is always bad. Requiring SQLite 3.7.17 as a minimum makes sure the sqlite3_strglob() function is available. That's an immediate gain. at (3): Advantage: official SQLite releases are better tested than intermediate ones. Fossil 1.27 contains a SQLite 2.8.1 beta with a bug which is crucial on Cygwin. See: http://osdir.com/ml/sqlite-users/2013-12/msg00193.html This bug is discovered during release testing of SQLite 2.8.2 (when I became Cygwin's SQLite maintainer), if fossil would have been compiled with --disable-internal-sqlite the bug would have been fixed now. at (4): If SQLite 2.8.3 is released around February, then a reasonable Fossil 1.29 release could be done mid 1014. That's more than enough time for whatever distribution to upgrade to SQLite 2.8.2. And it means that starting one month from now Fossil developers don't need to worry about WITHOUT ROWID support: just use it whenever appropriate. at (5): This means that part of the pre-release testing of every Fossil release should be a test using --disable-internal-sqlite, in order to verify that Fossil really works well with the lowest SQlite version it is documented to work with. I volunteer to do this pre-release test. On Cygwin, keeping --disable-internal-sqlite would have the advantage that fossil can take advantage of the improved win32-longpath VFS (and the new unix-cygwin VFS) without the Fossil maintainer (Jari Aalto) having to replace the SQLite amagalmation with every new Fossil release. As soon as the Cygwin enhancements are adopted by SQLite (in whatever modified form), --disable-internal-sqlite doesn't give any advantage on Cygwin any more. But as long as that doesn't happen, I hope that --disable-internal-sqlite will be kept as-is. Regards, Jan Nijtmans ___ 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] general question about multiple source-trees in 1 repo, and recursive diff
On 6 January 2014 12:53, Martin Gagnon eme...@gmail.com wrote: On Mon, Jan 06, 2014 at 09:24:53AM +0100, Michai Ramakers wrote: Hello, [snip] Is there a better way to do this..? Alternately, when diff'ing in the fossil web-UI by clicking/selecting the old checkin first, then the head, is there a way to only show Modified files? I recently merge a small change on trunk with this capability. Right now, you have a button Hide Diff (which mean show list of modified files only) when clicking on 2 commits from timeline. There's also a setting to hide the diff by default if you want. ah, is that the 'sbs=' option to vdiff? If so, what I meant was: can I somehow only see a list of Modified files, instead of a list of Added, Deleted and Modified? (I am already using 'sbs=0'). Michai ___ 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] tree-view of files
Michai Ramakers wrote: On 6 January 2014 11:59, Michai Ramakersm.ramak...@gmail.com wrote: Hello, I noticed that when clicking on 'files' in a checkin-summary (e.g. random checkin https://www.fossil-scm.org/index.html/info/f83e0d2123), tree-view is now displayed instead of legacy flat-dir. No complaints here, but was this intentional? (Is 'tree' the new 'dir'..?) actually... one obvious drawback is that due to expanding subdirs, the actual 1st-level files/subdirs are now scattered. Is there a way to use 'dir' as default, and 'tree'-view only when explicitly telling it to? (TBH I haven't read all of the tree-view details yet, chances are I missed it or am doing something wrong.) Michai Yeah, having everything expanded can be annoying. In the Fossil repo in particular, compat/zlib/ is huge. You have to scroll halfway down the page to get to src/, where most of the work gets done. I'm going to add some javascript for expanding/collapsing directories. Then the tree-view will be practically perfect in every way. ___ 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] tree-view of files
Joel Bruick wrote: I'm going to add some javascript for expanding/collapsing directories. Then the tree-view will be practically perfect in every way. And... done. For added convenience, you can also expand/collapse every subdirectory at once by clicking the root directory. ___ 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] general question about multiple source-trees in 1 repo, and recursive diff
On Mon, Jan 06, 2014 at 08:47:43PM +0100, Michai Ramakers wrote: On 6 January 2014 12:53, Martin Gagnon eme...@gmail.com wrote: On Mon, Jan 06, 2014 at 09:24:53AM +0100, Michai Ramakers wrote: Hello, [snip] Is there a better way to do this..? Alternately, when diff'ing in the fossil web-UI by clicking/selecting the old checkin first, then the head, is there a way to only show Modified files? I recently merge a small change on trunk with this capability. Right now, you have a button Hide Diff (which mean show list of modified files only) when clicking on 2 commits from timeline. There's also a setting to hide the diff by default if you want. ah, is that the 'sbs=' option to vdiff? If so, what I meant was: can I somehow only see a list of Modified files, instead of a list of Added, Deleted and Modified? (I am already using 'sbs=0'). I don't think it is possible right now.. -- Martin G. ___ 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] tree-view of files
Thus said Joel Bruick on Mon, 06 Jan 2014 18:50:57 -0500:
And... done. For added convenience, you can also expand/collapse every
subdirectory at once by clicking the root directory.
I wonder if it would be a good idea to change the class for tree-view
directories from ``dir'' to ``treedir'' so different CSS can be applied
to the different modes of viewing the files?
At the moment, I use the following CSS to put a / at the end of
directories for the flat-view, but it conflicts a bit with the
tree-view:
li.dir:after {
content: '/';
}
Other than this, it looks better and works well.
Thanks,
Andy
--
TAI64 timestamp: 400052cb69d5
___
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] tree-view of files
On Mon, Jan 6, 2014 at 6:50 PM, Joel Bruick j...@joelface.com wrote: Joel Bruick wrote: I'm going to add some javascript for expanding/collapsing directories. Then the tree-view will be practically perfect in every way. And... done. For added convenience, you can also expand/collapse every subdirectory at once by clicking the root directory. Tnx. That works great. It's on the server now, after a few modifications, such as adding the expand query parameter which causes the display to start in an expanded state. One issue I have: There is now no longer a way to get a tree for a subdirectory by itself, except to enter the name= query parameter manually in the URL. For example, you can no longer get to: http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand just by clicking. Then again, maybe I'm the only person who ever wants to do that so the missing capability is not important... -- 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] tree-view of files
Thus said Richard Hipp on Mon, 06 Jan 2014 21:48:40 -0500: just by clicking. Then again, maybe I'm the only person who ever wants to do that so the missing capability is not important... I think this is easily shown to be problematic by simply browsing to: http://www.fossil-scm.org/fossil/dir?ci=13c71a97feb26586name=src Then click Tree-View which gives: http://www.fossil-scm.org/fossil/dir?ci=13c71a97feb26586name=srctype=tree One has to manually add expand at this point to reveal the files. Perhaps Fossil should check it's query parameters when Tree-View is clicked and if ``name'' is in the set of parameters it should automatically add expand? Thanks, Andy -- TAI64 timestamp: 400052cb6e19 ___ 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] tree-view of files
Thus said Andy Bradford on 06 Jan 2014 20:01:13 -0700: Then click Tree-View which gives: http://www.fossil-scm.org/fossil/dir?ci=13c71a97feb26586name=srctype=tree One has to manually add expand at this point to reveal the files. Perhaps Fossil should check it's query parameters when Tree-View is clicked and if ``name'' is in the set of parameters it should automatically add expand? Actually, perhaps this is just a bug with the Javascript? Why shouldn't I be able to click on the directory node at that URL to cause the directory contents to expand? Maybe I should look more closely at the code to see what is being generated... Andy -- TAI64 timestamp: 400052cb6f30 ___ 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] tree-view of files
Richard Hipp wrote: Tnx. That works great. It's on the server now, after a few modifications, such as adding the expand query parameter which causes the display to start in an expanded state. One issue I have: There is now no longer a way to get a tree for a subdirectory by itself, except to enter the name= query parameter manually in the URL. For example, you can no longer get to: http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand just by clicking. Then again, maybe I'm the only person who ever wants to do that so the missing capability is not important... You can still middle/right click on the links to open the subdirectory pages, if you really need to scratch that itch. ___ 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] New Tree-View feature requires newer sqlite.
On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/4 Richard Hipp d...@sqlite.org: (3) After SQLite 3.8.3 is released, release fossil 1.28 with the EXACT SQLite 3.8.3 amalgamation included. I assume you do not mean here that Fossil v 1.28 should be released concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28 should be released when it is ready on or after the moment that SQLite release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such that the source for the SQLite release v 3.8.3 can be incorporated within the source for Fossil v 1.28. (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add WITHOUT ROWID to whatever SQL statement it is useful. Unconditionally! I assume here (and below) you mean SQLite 3.8.2, not 2.8.2 (and 3.8.3 instead of 2.8.3). I also assume you mean here that it be a runtime check requiring that *at* *least* SQLite 3.8.2 is available to Fossil (e.g. SQLite 3.8.2 *or later*), rather than a runtime check requiring that SQLite 3.8.2 *exactly* be available to Fossil. (Otherwise, Fossil builds using the embedded code copy of SQLite would fail at runtime, because you've just specified the embedded code copy of SQLite for this version of Fossil is 3.8.3 and not 3.8.2.) May I ask why that run-time check cannot or should not be made in the release version of Fossil 1.28, rather than immediately after it is tagged such that it will only take effect in a release version for Fossil 1.29? Sure, it means that distributions cannot distribute Fossil 1.28 (as released by Fossil upstream) using a system-provided shared library version of SQLite until they have updated that system-provided shared library version of SQLite to 3.8.2 from whatever version they currently have (call it v XY.ZZY), but so what? Distributions are used to this sort of thing, applications requiring a version of a system-provided library more recent than the version they currently make available. The distributions will just have to (1) provide a new version of the system-provided shared library version of SQLite that is sufficiently recent for Fossil v 1.28's needs (presumably either SQLite 3.8.2 or 3.8.3 at their discretion); (2) make sure that all the other applications they distribute that depend on SQLite, which currently work with SQLite v XY.ZZY, will work properly with the new version of SQLite whatever it ends up being, and patch or update those other applications as necessary; (3) make Fossil 1.28, the new version of SQLite, and any new versions of other apps available to their end-users, which the end-users can update to if and as they see fit to. (Well, unless the distributions patch their copy of Fossil v 1.28 to use their copy of SQLite v XY.ZZY, but they do that at their own risk and are responsible for all support of that combination. Fossil upstream devs will not support that combination of software.) This will require all end-users to update their copy of SQLite and possibly other applications depending on SQLite if they want to use the new release version of Fossil, but again so what? That's what distribution packaging, and distribution software update tools, are all about; to make sure that sort of thing works, everything is consistent and supported, etc. (5) Future official fossil release should contain an official released SQLite amagalmation as well, but less frequent: There is no need to make a new Fossil release after each SQLite release. I would agree that, unless part of the purpose (either explicit or implicit) for Fossil's existence is to act as a showcase and testbed for the latest and greatest available version of SQLite, there is no need to tie releases of Fossil to releases of SQLite. Release versions of Fossil should be made when they are appropriate and when they are ready, which does not necessarily have anything to do with the release schedule of SQLite. Further, release versions of Fossil should not necessarily require using the latest and greatest release version of SQLite, unless features and bug-fixes only available in that version of SQLite are required by the release version of Fossil to be made. Instead, release versions of Fossil should only require using the oldest version of SQLite providing the features that version of Fossil needs which the Fossil devs *are* *willing* *to* *support* for that version of Fossil. (If the Fossil devs say We only support using the latest and greatest release version of SQLite available at the time we made this release version of Fossil, well then so be it. The Fossil devs are volunteers, presumably not being paid (in general) to develop and support Fossil, and are not required to do anything they do not want to do.) In particular... If Fossil version M requires using SQLite version N, and if Fossil version M+1 does not require any
Re: [fossil-users] tree-view of files
On Tue, Jan 7, 2014 at 4:48 AM, Richard Hipp d...@sqlite.org wrote: Tnx. That works great. It's on the server now, after a few modifications, such as adding the expand query parameter which causes the display to start in an expanded state. One issue I have: There is now no longer a way to get a tree for a subdirectory by itself, except to enter the name= query parameter manually in the URL. For example, you can no longer get to: http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand just by clicking. Then again, maybe I'm the only person who ever wants to do that so the missing capability is not important... Bug: In the above link, try clicking on the compat directory name in the first line. It will supposedly take you to the compat listing, but it will be empty ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
